From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel Schnell" Subject: Q: is the ALSA-lib API thread-safe Date: Thu, 5 Aug 2004 09:57:00 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: <1e2101c47ac1$ca702340$2c0aa8c0@lumpidu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1E1E_01C47AD2.8D665030" Return-path: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org This is a multi-part message in MIME format. ------=_NextPart_000_1E1E_01C47AD2.8D665030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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:=20 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. ------=_NextPart_000_1E1E_01C47AD2.8D665030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

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


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

Confused,

Ciao,

Daniel.
------=_NextPart_000_1E1E_01C47AD2.8D665030-- ------------------------------------------------------- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clemens Ladisch Subject: Re: Q: is the ALSA-lib API thread-safe Date: Thu, 05 Aug 2004 12:06:55 +0200 (METDST) Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <1e2101c47ac1$ca702340$2c0aa8c0@lumpidu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: In-reply-to: <1e2101c47ac1$ca702340$2c0aa8c0@lumpidu> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Daniel Schnell Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Davis Subject: Re: Q: is the ALSA-lib API thread-safe Date: Thu, 05 Aug 2004 08:31:30 -0400 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: <200408051231.i75CVUt8027083@localhost.localdomain> References: Return-path: In-reply-to: Your message of "Thu, 05 Aug 2004 12:06:55 +0200." Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Clemens Ladisch Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org >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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaroslav Kysela Subject: Re: Q: is the ALSA-lib API thread-safe Date: Thu, 5 Aug 2004 14:51:13 +0200 (CEST) Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <200408051231.i75CVUt8027083@localhost.localdomain> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <200408051231.i75CVUt8027083@localhost.localdomain> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Paul Davis Cc: Clemens Ladisch , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 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 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