play~ audio quality problems

    pmt
    Mar 16 2006 | 3:30 pm
    Hi,
    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.
    Best,
    Peter Traub
    • pmt
      Mar 16 2006 | 3:40 pm
      Apologies. It seems the binary file I attached may cause some problems. Here is a text version.
      Best,
      Peter
    • projects
      Mar 16 2006 | 4:34 pm
      Hi Peter,
      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.
      Ben
    • pmt
      Mar 16 2006 | 6:15 pm
      Hi Ben,
      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.
      Best,
      Peter
    • Peter McCulloch
      Mar 16 2006 | 6:42 pm
      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.
      Peter McCulloch
    • pmt
      Mar 16 2006 | 7:56 pm
      Hi Peter,
      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.
      Best,
      Peter
    • Stefan Tiedje
      Mar 17 2006 | 9:44 am
      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
      --
      [][] [][][] [][] [][][] [][][][][][][][][][][][][][][]
      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