Q: is the ALSA-lib API thread-safe

Q: is the ALSA-lib API thread-safe

[Daniel Schnell]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Hi,

is the ALSA-Lib-API thread-safe concerning the following scenario:


in thread 1 the audio-processing takes place via snd_pcm_avail_update(), 
snd_pcm_begin(), snd_pcm_commit(). In thread 2 I call the functions: 
snd_pcm_hwsync(), snd_pcm_avail_update() to get the actual delay via
bufferframes - snd_pcm_avail_update(). Should I lock these calls or
should I use instead snd_pcm_avail() in thread 2 ?
Is there any difference concerning thread-safety between the hw: layer or the plug: layer ?

Confused,

Ciao,

Daniel.

[-- Attachment #2: Type: text/html, Size: 1369 bytes --]

Re: Q: is the ALSA-lib API thread-safe

[Clemens Ladisch]

Daniel Schnell wrote:
> is the ALSA-Lib-API thread-safe concerning the following scenario:
>
> in thread 1 the audio-processing takes place via snd_pcm_avail_update(),
> snd_pcm_begin(), snd_pcm_commit(). In thread 2 I call the functions:
> snd_pcm_hwsync(), snd_pcm_avail_update() to get the actual delay via
> bufferframes - snd_pcm_avail_update().

The snd_pcm_t* handle which you're using in both threads refers to one
data structure in alsa-lib which isn't protected against concurrent
accesses.

> Is there any difference concerning thread-safety between the hw:
> layer or the plug: layer ?

No, both go through alsa-lib.


HTH
Clemens




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Q: is the ALSA-lib API thread-safe

[Paul Davis]

>Daniel Schnell wrote:
>> is the ALSA-Lib-API thread-safe concerning the following scenario:
>>
>> in thread 1 the audio-processing takes place via snd_pcm_avail_update(),
>> snd_pcm_begin(), snd_pcm_commit(). In thread 2 I call the functions:
>> snd_pcm_hwsync(), snd_pcm_avail_update() to get the actual delay via
>> bufferframes - snd_pcm_avail_update().
>
>The snd_pcm_t* handle which you're using in both threads refers to one
>data structure in alsa-lib which isn't protected against concurrent
>accesses.

how true. its a bit ironic that one of the big advances of ALSA's
kernel code over OSS is the addition of thread safety, and that
another is the use of a user-space library to mediate access. the
combination of the two, however, eliminates thread safety :(



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Q: is the ALSA-lib API thread-safe

[Jaroslav Kysela]

On Thu, 5 Aug 2004, Paul Davis wrote:

> >Daniel Schnell wrote:
> >> is the ALSA-Lib-API thread-safe concerning the following scenario:
> >>
> >> in thread 1 the audio-processing takes place via snd_pcm_avail_update(),
> >> snd_pcm_begin(), snd_pcm_commit(). In thread 2 I call the functions:
> >> snd_pcm_hwsync(), snd_pcm_avail_update() to get the actual delay via
> >> bufferframes - snd_pcm_avail_update().
> >
> >The snd_pcm_t* handle which you're using in both threads refers to one
> >data structure in alsa-lib which isn't protected against concurrent
> >accesses.
> 
> how true. its a bit ironic that one of the big advances of ALSA's
> kernel code over OSS is the addition of thread safety, and that
> another is the use of a user-space library to mediate access. the
> combination of the two, however, eliminates thread safety :(

Above scenario seems worth to support. Also I cannot imagine other 
useability to make other functions reentrant.

The avail_update() + mmap + r/w functions are not much reentrant, but 
you may use in the second thread snd_pcm_delay() which should be
(not verified) reentrant and callable at any time without influence
for avail_update() + r/w operations.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com