I've been using play~ to play back sounds loaded into a buffer~, and 

have discovered that the sound quality seems to be a problem. The 

playback sounds like it is being slightly ring-modulated, or that it is 

showing the effects of a sample-rate mismatch. In any case, to test out 

the problem, I tried playing the buffer back with wave~, and the issue 

did not occur. I am driving play~ with a line~ object, and thought that 

that might also be the problem, so I replaced the line~ with a phasor~ 

The attached patch demonstrates the issue. Load a 1 minute stereo sample 

in the buffer, and then turn on the DAC. Both play~ and wave~ will 

playback simultaneously, but you can x-fade between the two to hear the 

sound quality difference. Any insight as to why this might be happening 

and what I could do to prevent it would be greatly appreciated. Many 

I've been using play~ to play back sounds loaded into a buffer~, and 
have discovered that the sound quality seems to be a problem. The 
playback sounds like it is being slightly ring-modulated, or that it is 
showing the effects of a sample-rate mismatch. In any case, to test out 
the problem, I tried playing the buffer back with wave~, and the issue 
did not occur. I am driving play~ with a line~ object, and thought that 
that might also be the problem, so I replaced the line~ with a phasor~ 
but the problem persisted.

The attached patch demonstrates the issue. Load a 1 minute stereo sample 
in the buffer, and then turn on the DAC. Both play~ and wave~ will 
playback simultaneously, but you can x-fade between the two to hear the 
sound quality difference. Any insight as to why this might be happening 
and what I could do to prevent it would be greatly appreciated. Many 
thanks in advance.

play-audio-quality-problems

Apologies. It seems the binary file I attached may cause some problems. 

Apologies. It seems the binary file I attached may cause some problems. 
Here is a text version.

I tried the patch you sent and couldn't reproduce the effect. 

Sometimes with long sound files there is a problem with the bit depth

of the playback signal that results in playback degradation, but "ring

modulated" isn't really how I would describe the sound... anyway, you

https://cycling74.com/twiki/bin/view/Share/JoshuaKitClayton)

that fixes your problem. Otherwise the only thing I can suggest is to

make your one minute sound file available somewhere on the web so that

I tried the patch you sent and couldn't reproduce the effect. 
Sometimes with long sound files there is a problem with the bit depth
of the playback signal that results in playback degradation, but "ring
modulated" isn't really how I would describe the sound... anyway, you
could try Joshua's hi-res objects
 (https://cycling74.com/twiki/bin/view/Share/JoshuaKitClayton) to see if
that fixes your problem.  Otherwise the only thing I can suggest is to
make your one minute sound file available somewhere on the web so that
we can test that.

Yes, I suppose bit-depth degradation might be a better description of 

the sound, and it does happen over time. In my actual application, I'm 

using a 10 min. buffer and not the 1 min. one in my test file, so the 

problem is even more accute. In any case, I've uploaded a 1 min. test 

sound to the web that you can download and hear the issue with. It is at:

http://www.people.virginia.edu/~pmt4u/testsnd.aif

After about 15 seconds of playback in the test patch, try hard x-fading 

between the play~ and wave~ output (i.e., listen fully to one and then 

the other), and the difference between the two should become quite 

audible. It becomes more audible over time. I will check out the hi-res 

objects you suggest, but I'm curious why this problem exists with play~ 

in the first place and if there is some sort of workaround? Many thanks.

Yes, I suppose bit-depth degradation might be a better description of 
the sound, and it does happen over time. In my actual application, I'm 
using a 10 min. buffer and not the 1 min. one in my test file, so the 
problem is even more accute. In any case, I've uploaded a 1 min. test 
sound to the web that you can download and hear the issue with. It is at:

After about 15 seconds of playback in the test patch, try hard x-fading 
between the play~ and wave~ output (i.e., listen fully to one and then 
the other), and the difference between the two should become quite 
audible. It becomes more audible over time. I will check out the hi-res 
objects you suggest, but I'm curious why this problem exists with play~ 
in the first place and if there is some sort of workaround? Many thanks.

You might compare it with the different interpolation modes on wave~. 

(try interp 0, 1, 2) Mode 2 is high quality, mode 1 is default, mode 0 

is off. Sorry, not a solution, but might reveal what's going on.

You might compare it with the different interpolation modes on wave~.  
(try interp 0, 1, 2)  Mode 2 is high quality, mode 1 is default, mode 0 
is off.  Sorry, not a solution, but might reveal what's going on.

Upon reading the docs for the hi.res objects, it seems that it is a bit 

resolution issue. I have replaced my core playback module, that used 

line~, play~, and pong~ with the hi.res objects hr.line~, hr.play~, and 

hr.wrap~. They appear to do the trick in both the test application I 

posted to the list and my main application. However, they do appear to 

incur the cost of higher CPU utilization, meaning my poly~ instrument 

that uses these playback objects can't have as many instances of them.

Btw, I did try playing with the interp modes for wave~, but interp 0, 

while giving noticeably diminished quality, did not give the same sort 

of effect as I was hearing with play~. Many thanks.

Upon reading the docs for the hi.res objects, it seems that it is a bit 
resolution issue. I have replaced my core playback module, that used 
line~, play~, and pong~ with the hi.res objects hr.line~, hr.play~, and 
hr.wrap~. They appear to do the trick in both the test application I 
posted to the list and my main application. However, they do appear to 
incur the cost of higher CPU utilization, meaning my poly~ instrument 
that uses these playback objects can't have as many instances of them.

Btw, I did try playing with the interp modes for wave~, but interp 0, 
while giving noticeably diminished quality, did not give the same sort 
of effect as I was hearing with play~. Many thanks.

If you use the phase related playback methods on longer sound files than

ca. 6 min 20 seconds you will run into that problem, and ist obvious,

dealing with higher resolution will need more CPU.

Most things you can do with play~ and wave~, you could also do with

groove~. As you just start the playback, and then the object runs on its 

own, sample by sample. I guess redoing your approach with groove~'s 

might save you the missing CPU cycles. You could use the groove~'s sync 

outlet as you master if you need one. Though the resolution problem 

would then arise there as well, but you might not need the high 

resolution there. Depends on what you're doing...

If you use the phase related playback methods on longer sound files than
ca. 6 min 20 seconds you will run into that problem, and ist obvious,
dealing with higher resolution will need more CPU.
Most things you can do with play~ and wave~, you could also do with
groove~. As you just start the playback, and then the object runs on its 
own, sample by sample. I guess redoing your approach with groove~'s 
might save you the missing CPU cycles. You could use the groove~'s sync 
outlet as you master if you need one. Though the resolution problem 
would then arise there as well, but you might not need the high 
resolution there. Depends on what you're doing...

  [][]  [][][]  [][]  [][][]
[][][][][][][][][][][][][][][]

         Stefan Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


play~ audio quality problems