play~ audio quality problems

    Mar 16 2006 | 3:30 pm
    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.
    Peter Traub

    • Mar 16 2006 | 3:40 pm
      Apologies. It seems the binary file I attached may cause some problems.
      Here is a text version.
      max v2;
    • 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
      ( 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.
    • 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:
      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.
    • 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
    • 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~,, 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.
    • 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 Tiedje
      Electronic Composition
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09