ALSA (snd_pcm_plugin_write) behavior questions

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
#1

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

#2

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

#3

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

#4

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.

#5

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

#6

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