#1082 inconsistent latency with mmio/asio

puredata (322)

If I put 500 in the Delay(ms) using MMIO in the audio settings changes are heard faster than 500ms in ASIO. tested with a toggle to a (*~) in between osc~ and dac~ in 0.43.4-extended.
This didn`t happened in previous versions.
500 ms ahead of the soundfile that is to be played is paradise in aleatory music and MMIO bypasses asio4all installation and configuration for listeners of the abstractions that I share on the net.

Pd version 0.43.4-extended
XP-sp3 / Intel PIV
built-in sound


  • IOhannes m zmölnig

    • summary: mmio --> inconsistent latency with mmio/asio
    • assigned_to: eighthave --> nobody
    • labels: 845074 --> puredata
  • IOhannes m zmölnig

    i think the "audfiobuffer" settings (aka: "Delay [ms]") in the audio preferences is considered a "hint" rather than an absolute value: it attemtps to configure the audio backend with a certain buffer; whether the backend can acquire that buffer is out of the control of Pd.

    furthermore, the absolute latency of the system is depending on your entire setup (of which Pd and the audio-backend are only a small part).
    if you need to be able to set an absolute latency of your system, i'm afraid the only way is to measure the system delay and delay the audio signal appropriately using [delwrite~]/[delread~].

    if you simply need some delay between action (e.g. user-input) and reaction (e.g. soundfile playback), you might want to use [delay] rather than fuddling around with the audio-settings.

  • IOhannes m zmölnig

    • status: open --> pending-works-for-me
  • lucarda

    lucarda - 2013-05-27

    Ok, audiobuffer settings, in this model, is an effective way to deal with slow hardware.

    Readsf~ bangs when finishes playing a soundfile, this bang triggers the same readsf~ to open and play a randomly chosen file (open $1.wav, 1).

    Since readsf~ has to go to that file wherever it is and start reading, the audiobuffer setting allows gap-less playback between files.

    If I give 500ms readsf~ will have half a second to go anywhere in the hard-drive and start streaming.

    5400rpm hard-drives need more time to achieve this than a Pendrive. My netbook plays my abstractions (with more than 3 readsf~ simultaneously) with 100ms with no problem from a Pendrive but need 500ms to do it from the 5400rpm hard-drive.

    Here the point is that 500ms using ASIO is fine but 500ms in MMIO has gaps. And as mentioned previously with the toggle and the osc~ it feels that MMIO is computing faster than 500ms.

    I think that in this situation the audiobuffer is a kind of read ahead for readsf~ which is very useful.

    And of course I`m not sure that there is a bug, perhaps is my computer.

  • lucarda

    lucarda - 2013-05-27
    • status: pending-works-for-me --> open-works-for-me
  • IOhannes m zmölnig

    if you want to buffer file reading using [readsf~], you probably should use [readsf~]s built-in buffer for that.

    something like: use 2 [readsf~] objects that are used alternatingly. *open* the 2nd file (in the 2nd [readsf~]) while the 1st file is still playing; use the EOF of file#1 to start playing back (the already opened) file#2.

  • lucarda

    lucarda - 2013-05-29

    Absolutely, I`ve started working with 2 [readsf~] along with [soundfile_info] or this can be replaced with data in a table.

    Much better than asking the listeners to go to audio-settings and all that.

    I don`t know if it is a bug but is a difference to 042.

    I will be updating my abstractions to put them in a less “raw” state.

    I don`t have more to say, this one can also be closed.

    Thanx IOhannes,

    If I find something I`ll report it.


  • IOhannes m zmölnig

    • status: open-works-for-me --> closed-works-for-me


Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks