ALSA (snd_pcm_plugin_write) behavior questions

Playing with the ALSA sound library.

I have a mutlithreaded application with its own audio I/O thread.

I’d like to be able to quickly reset an audio clip to start playing from
its beginning.

Attempt 1) Single write thread doing the playing. Use
‘snd_pcm_playback_drain’ (on another thread) to immediately cutoff the
sound. Works great, except the write thread takes way too much time
to pop back out, so I can submit a new write.

Attempt 2) Multiple write threads. Every time I want to reset the
audio, I ‘snd_pcm_playback_drain’ and then start up a new write thread
(using the same handle). Audio gets garbled.

Attempt 3) Multiple write threads, multiple handle. Every time I want
to reset the audio, I ‘snd_pcm_playback_drain’ then start up a new
thread, doing another ‘snd_pcm_open’ for each thread. Works great,
… however seems to have a handle limit, as the ‘snd_pcm_open’
blocks after something like 4-6 opens, waiting for one of the other
handles to free up. Not good as I’m back to waiting for the write
thread to pop out, so I can close the handle its using.

Any other ideas? Is there a way to interrupt the write? I’d like to
stay with a single thread, if possible, but I don’t like the delay that
it takes to finally pop out of the write. Will it help if I boost the
priority of the write thread? I’m quickly running out of other things
to try, so thought I’d ask here.


Regards,
Jon Grimm

How should snd_pcm_playback_drain behave? The documentation claims it to
be useful for switching tracks and pause button functionality. I’m trying
to use it for basically this function. I start a write… which blocks,
then use ‘drain’, followed by a new ‘write’. However, if I start doing I/O
to the same audio device handle, I get garbage, until the original write
thread pops up out of snd_pcm_plugin_write.

jon grimm wrote:

Playing with the ALSA sound library.

I have a mutlithreaded application with its own audio I/O thread.

I’d like to be able to quickly reset an audio clip to start playing from
its beginning.

Attempt 1) Single write thread doing the playing. Use
‘snd_pcm_playback_drain’ (on another thread) to immediately cutoff the
sound. Works great, except the write thread takes way too much time
to pop back out, so I can submit a new write.

Attempt 2) Multiple write threads. Every time I want to reset the
audio, I ‘snd_pcm_playback_drain’ and then start up a new write thread
(using the same handle). Audio gets garbled.

Attempt 3) Multiple write threads, multiple handle. Every time I want
to reset the audio, I ‘snd_pcm_playback_drain’ then start up a new
thread, doing another ‘snd_pcm_open’ for each thread. Works great,
… however seems to have a handle limit, as the ‘snd_pcm_open’
blocks after something like 4-6 opens, waiting for one of the other
handles to free up. Not good as I’m back to waiting for the write
thread to pop out, so I can close the handle its using.

Any other ideas? Is there a way to interrupt the write? I’d like to
stay with a single thread, if possible, but I don’t like the delay that
it takes to finally pop out of the write. Will it help if I boost the
priority of the write thread? I’m quickly running out of other things
to try, so thought I’d ask here.

Regards,
Jon Grimm

Weird. I will have to take a look at this.
Do you have a short test case that you can
post? It would save some time.

Thanks,
James M.

Jon Grimm <jgrimm@us.ibm.com> wrote:

How should snd_pcm_playback_drain behave? The documentation claims it to
be useful for switching tracks and pause button functionality. I’m trying
to use it for basically this function. I start a write… which blocks,
then use ‘drain’, followed by a new ‘write’. However, if I start doing I/O
to the same audio device handle, I get garbage, until the original write
thread pops up out of snd_pcm_plugin_write.

jon grimm wrote:

Playing with the ALSA sound library.

I have a mutlithreaded application with its own audio I/O thread.

I’d like to be able to quickly reset an audio clip to start playing from
its beginning.

Attempt 1) Single write thread doing the playing. Use
‘snd_pcm_playback_drain’ (on another thread) to immediately cutoff the
sound. Works great, except the write thread takes way too much time
to pop back out, so I can submit a new write.

Attempt 2) Multiple write threads. Every time I want to reset the
audio, I ‘snd_pcm_playback_drain’ and then start up a new write thread
(using the same handle). Audio gets garbled.

Attempt 3) Multiple write threads, multiple handle. Every time I want
to reset the audio, I ‘snd_pcm_playback_drain’ then start up a new
thread, doing another ‘snd_pcm_open’ for each thread. Works great,
… however seems to have a handle limit, as the ‘snd_pcm_open’
blocks after something like 4-6 opens, waiting for one of the other
handles to free up. Not good as I’m back to waiting for the write
thread to pop out, so I can close the handle its using.

Any other ideas? Is there a way to interrupt the write? I’d like to
stay with a single thread, if possible, but I don’t like the delay that
it takes to finally pop out of the write. Will it help if I boost the
priority of the write thread? I’m quickly running out of other things
to try, so thought I’d ask here.

Regards,
Jon Grimm

Yeah, I didn’t have time today. Hopefully tomorrow will be a little calmer.

jamesm@qnx.com wrote:

Weird. I will have to take a look at this.
Do you have a short test case that you can
post? It would save some time.

James,
Test case isn’t very short, so I put it on my quics account. jagrimm.

See auplay.zip:

usage: auplay filename

Description:
goes into getchar loop.

lay and top.
spins off new thread for every write. stop just does a snd_pcm_playback_drain


Regards,
Jon Grimm

jamesm@qnx.com wrote:

Weird. I will have to take a look at this.
Do you have a short test case that you can
post? It would save some time.

Thanks,
James M.

Jon Grimm <> jgrimm@us.ibm.com> > wrote:
How should snd_pcm_playback_drain behave? The documentation claims it to
be useful for switching tracks and pause button functionality. I’m trying
to use it for basically this function. I start a write… which blocks,
then use ‘drain’, followed by a new ‘write’. However, if I start doing I/O
to the same audio device handle, I get garbage, until the original write
thread pops up out of snd_pcm_plugin_write.

jon grimm wrote:

Playing with the ALSA sound library.

I have a mutlithreaded application with its own audio I/O thread.

I’d like to be able to quickly reset an audio clip to start playing from
its beginning.

Attempt 1) Single write thread doing the playing. Use
‘snd_pcm_playback_drain’ (on another thread) to immediately cutoff the
sound. Works great, except the write thread takes way too much time
to pop back out, so I can submit a new write.

Attempt 2) Multiple write threads. Every time I want to reset the
audio, I ‘snd_pcm_playback_drain’ and then start up a new write thread
(using the same handle). Audio gets garbled.

Attempt 3) Multiple write threads, multiple handle. Every time I want
to reset the audio, I ‘snd_pcm_playback_drain’ then start up a new
thread, doing another ‘snd_pcm_open’ for each thread. Works great,
… however seems to have a handle limit, as the ‘snd_pcm_open’
blocks after something like 4-6 opens, waiting for one of the other
handles to free up. Not good as I’m back to waiting for the write
thread to pop out, so I can close the handle its using.

Any other ideas? Is there a way to interrupt the write? I’d like to
stay with a single thread, if possible, but I don’t like the delay that
it takes to finally pop out of the write. Will it help if I boost the
priority of the write thread? I’m quickly running out of other things
to try, so thought I’d ask here.

Regards,
Jon Grimm

Thought, I’d answer here in case anyone came across.

The 9/26 driver cleared up most of my problems as the drain immediately cuts off
sound and interrupts
the write thread. This was the behavior I wanted.

However, I still find it a little distrurbing the snd_pcm_open can block, as I’d
expect it to return -EBUSY per the specs (especially when I set NONBLOCK flag on
open).

Regards,
Jon Grimm