[alsa-devel] Asynchronous ALSA - callback and latency questions
Hello all,
I’m using ALSA for building a performance musical instrument, so I’m after low-latency audio output. I have some questions (since I'm fairly new to ALSA and to Linux they may be a big n00by, so please bear with me)…
1. I’m using asynchronous audio output (i.e. using a callback). Sometimes the system simply stops calling the callback function without giving an error. In case of an xrun I would expect there to be an underrun message (which I sometimes also get) so I can handle it properly. So I guess something else is causing the issue? Any pointers?
2. What does “File descriptor is in a bad state” mean, when it is returned by snd_pcm_writei? I notice that I can often avoid getting it by increasing the size of my buffer but the message doesn't make sense to me.
3. Occasionally my application grinds to a halt with a “I/O is possible” message – presumably this is triggered by the ALSA callback mechanism?
4. My last question is a bit more conceptual: what determines the playback latency of my audio stream? The period size? The total ring buffer size? I assume it should be the difference between the hardware playback pointer and the software write pointer, but I can’t figure out how they are determined.
Thanks for any help.
System info: Raspberry Pi B+ (non-overclocked), Raspbian Wheezy, USB PnP CM108 audio device
Bram Bos wrote:
I’m using ALSA for building a performance musical instrument, so I’m after low-latency audio output.
- I’m using asynchronous audio output (i.e. using a callback).
Don't. Many devices do not support this, and asynchronous callbacks run in a signal handler, where you must use only signal-safe functions.
- What does “File descriptor is in a bad state” mean, when it is returned by
snd_pcm_writei?
That the device is neither running, nor in an underrun state.
- what determines the playback latency of my audio stream?
The buffer size. When you fill the buffer completely, the last sample must wait for all previous samples to be played.
Regards, Clemens
I’m using ALSA for building a performance musical instrument, so I’m after low-latency audio output.
- I’m using asynchronous audio output (i.e. using a callback).
Don't.
That's an interesting insight. I reckoned using a callback was the most elegant solution since that's what I'm used to for DirectSound, iOS, OSX, WMME, ASIO etc.
So what would be the most bulletproof way of dealing with streaming audio instead? Can I do polling in a non-blocking state? I think blocking-state audio is out of the question since I do need to handle MIDI I/O and UI events at the same time.
Thanks Bram
At Tue, 9 Sep 2014 10:44:01 +0200 (CEST), Bram Bos wrote:
I’m using ALSA for building a performance musical instrument, so I’m after low-latency audio output.
- I’m using asynchronous audio output (i.e. using a callback).
Don't.
That's an interesting insight. I reckoned using a callback was the most elegant solution since that's what I'm used to for DirectSound, iOS, OSX, WMME, ASIO etc.
If you want to go in that direction, just use JACK. All you needed are found there.
Takashi
I’m using ALSA for building a performance musical instrument, so I’m after low-latency audio output.
- I’m using asynchronous audio output (i.e. using a callback).
Don't.
That's an interesting insight. I reckoned using a callback was the most elegant solution since that's what I'm used to for DirectSound, iOS, OSX, WMME, ASIO etc.
If you want to go in that direction, just use JACK.
And the next best alternative would be blocked-mode/polling through ALSA, then?
I'd prefer to have as few software interface layer dependencies as comfortably possible, so if I can get away with using only ALSA without requiring JACK that would be a plus for me.
Thanks Bram
Bram Bos wrote:
I’m using ALSA for building a performance musical instrument, so I’m after low-latency audio output.
- I’m using asynchronous audio output (i.e. using a callback).
Don't.
That's an interesting insight. I reckoned using a callback was the most elegant solution since that's what I'm used to for DirectSound, iOS, OSX, WMME, ASIO etc.
If you want to go in that direction, just use JACK.
And the next best alternative would be blocked-mode/polling through ALSA, then?
Yes. (That's what Jack uses; with full duplex, you already need to handle multiple devices.)
Regards, Clemens
participants (3)
-
Bram Bos -
Clemens Ladisch -
Takashi Iwai