Single process freeze when opening capture device

Single process freeze when opening capture device

[Arthur Peters]

I have found what seems to be a bug in ALSA (CVS of this afternoon).
When a program opens certain PCM devices for capture the program blocks
forever in snd_pcm_open (both the library function and the kernel
function actually). The PCM device I have been testing it with is
surround40 on a emu10k1 (SBLive Value). I am trying to capture on this
device because I want to have jack use surround40 (actually a route
plugin device pointing to it) so that I can use all 4 outs and both ins
at the same time.

Below is a minimal setup that reproduces the problem for me.

alsa_freeze.c
------------------
#include <alsa/asoundlib.h>
 
int main( int argc, char* argv[] )
{
        snd_pcm_t *pcm;
        snd_pcm_open(&pcm, "surround40", SND_PCM_STREAM_CAPTURE, 0);
        return 0;
}
------------------

.asoundrc
------------------
<confdir:cards/EMU10K1.conf>
------------------

using SysRq-T I captured a kernel stack trace
------------------
Using defaults from ksymoops -t elf32-i386 -a i386
Call Trace:    [<e094908e>] [<e0922b20>] [<e0948f60>] [<e091b220>]
[<c018c325>]
  [<c014bf59>] [<c013ea43>] [<c013e968>] [<c013ed43>] [<c010774f>]
Warning (Oops_read): Code line not seen, dumping what data is available
 
Proc;  alsa_test_sim
 
>>EIP; 00000000 Before first symbol
 
Trace; e094908e <[snd-pcm]snd_pcm_open+12e/190>
Trace; e0922b20 <[snd]snd_fops+0/48>
Trace; e0948f60 <[snd-pcm]snd_pcm_open+0/190>
Trace; e091b220 <[snd]snd_open+e0/160>
Trace; c018c325 <devfs_open+195/210>
Trace; c014bf59 <path_lookup+39/40>
Trace; c013ea43 <dentry_open+d3/1e0>
Trace; c013e968 <filp_open+68/70>
Trace; c013ed43 <sys_open+53/c0>
Trace; c010774f <system_call+33/38>
------------------

I suspect that snd_pcm_open+12e is line 1974 in pcm_native.c. Everytime
I checked it was at this address.
------------------
		set_current_state(TASK_INTERRUPTIBLE);
                schedule();
           >>>> if (signal_pending(current)) { <<<
                        err = -ERESTARTSYS;
                        break;
                }
------------------

Please tell me you need anymore info or if you want me to try anything.

-Arthur


-- 
Arthur Peters <amp@singingwizard.org>



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Single process freeze when opening capture device

[Jaroslav Kysela]

On Wed, 28 May 2003, Arthur Peters wrote:

> I have found what seems to be a bug in ALSA (CVS of this afternoon).
> When a program opens certain PCM devices for capture the program blocks
> forever in snd_pcm_open (both the library function and the kernel
> function actually). The PCM device I have been testing it with is
> surround40 on a emu10k1 (SBLive Value). I am trying to capture on this
> device because I want to have jack use surround40 (actually a route
> plugin device pointing to it) so that I can use all 4 outs and both ins
> at the same time.
> 
> Below is a minimal setup that reproduces the problem for me.
> 
> alsa_freeze.c
> ------------------
> #include <alsa/asoundlib.h>
>  
> int main( int argc, char* argv[] )
> {
>         snd_pcm_t *pcm;
>         snd_pcm_open(&pcm, "surround40", SND_PCM_STREAM_CAPTURE, 0);
>         return 0;
> }

It is limit of current alsa-lib configuration. We cannot distinct playback
and capture. But I am not sure, if returning an error helps you
(surround40 configuration is NOT valid for emu10k1). I suggest to fix jack
to allow different names for playback and capture with different count of
channels.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Single process freeze when opening capture device

[Abramo Bagnara]

Jaroslav Kysela ha scritto:
> On Wed, 28 May 2003, Arthur Peters wrote:
> 
> 
>>I have found what seems to be a bug in ALSA (CVS of this afternoon).
>>When a program opens certain PCM devices for capture the program blocks
>>forever in snd_pcm_open (both the library function and the kernel
>>function actually). The PCM device I have been testing it with is
>>surround40 on a emu10k1 (SBLive Value). I am trying to capture on this
>>device because I want to have jack use surround40 (actually a route
>>plugin device pointing to it) so that I can use all 4 outs and both ins
>>at the same time.
>>
>>Below is a minimal setup that reproduces the problem for me.
>>
>>alsa_freeze.c
>>------------------
>>#include <alsa/asoundlib.h>
>> 
>>int main( int argc, char* argv[] )
>>{
>>        snd_pcm_t *pcm;
>>        snd_pcm_open(&pcm, "surround40", SND_PCM_STREAM_CAPTURE, 0);
>>        return 0;
>>}
> 
> 
> It is limit of current alsa-lib configuration. We cannot distinct playback
> and capture. But I am not sure, if returning an error helps you
> (surround40 configuration is NOT valid for emu10k1). I suggest to fix jack
> to allow different names for playback and capture with different count of
> channels.
> 

What about a "dir" field in common section of pcm configuration?

   dir STR	# PCM allowed directions "playback", "capture", "both" (default)

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Single process freeze when opening capture device

[Jaroslav Kysela]

On Thu, 29 May 2003, Abramo Bagnara wrote:

> What about a "dir" field in common section of pcm configuration?
> 
>    dir STR	# PCM allowed directions "playback", "capture", "both" (default)

I'd like to solve the problem with same names, but different 
configurations for streams.

I have an idea like:

pcm.name {
	... global configuration ...
	playback {
		... playback configuration ...
	}
	capture {
		... capture configuration ...
	}
}

Also, we have copy of configuration for each open which is used for 
run-time evaluation. I think that we may pass from the open code some more 
information and use some {} region as data caching:

private {	# reserved for internal data only, warn and ignore if user defines it
	direction playback
	ctl_cache_handle 0x%p		# cache ctl handle for runtime evaluation
	... etc, etc ...
}

We may add condition (if - else) evaluation functions to runtime parsing 
which can test the contents of private variables. Now, we have same driver 
with different chip revisions which add/remove some features (mainly 
controls) and we need to test them to behave correctly.

Also, the first proposal requires to change all plugins, the later will 
rewrite the configuration at run-time, so no changes are required for 
plugins.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

hdsp9652+alsamixer -> kernel panic

[d]

dear alsa gurus!
i'm trying to get a rme hdsp 9652 to work, and have bad results:
loading snd-hammerfall-mem and snd-hdsp works fine, starting jack or 
some alsa-playback too (or at least seems to).
but when i start alsamixer or alsactl and want to unmute the channels i 
get massive xruns and no sound, sometimes a kernel panic.
i tried a pentium3- and a amd-duron system and ran into the same behavior.
the card worked for the previous owner, but i have no windows-system to 
test it there.

has anybody had similar expiriences or any hints for me?
regards
d13b


my setup:
rme hdsp 9652 with adi8-ae interface
kernel 2.4.20 (straight forward)
latest alsa from cvs

cat /proc/asound/card0/hdsp  gives me:

RME HDSP 9652 (Card #1)
Buffers: capture d4000000 playback d3e00000
IRQ: 12 Registers bus: 0xeb000000 VM: 0xdc8a2000
Control register: 0x10080de
Status register: 0x3400008
Status2 register: 0xffff8041
FIFO status: 0
MIDI1 Output status: 0xffffff00
MIDI1 Input status: 0xffffff38
MIDI2 Output status: 0xffffff00
MIDI2 Input status: 0xffffff38

Buffer Size (Latency): 8192 samples (2 periods of 32768 bytes)
Hardware pointer (frames): 0
Passthru: no
Line out: on
Firmware version: 1

Sample Clock Source: Internal 48 kHz
Preferred Sync Reference: ADAT1
AutoSync Reference: ADAT1
AutoSync Frequency: 44100
System Clock Mode: Master
System Clock Frequency: 48000

IEC958 input: Internal
IEC958 output: Coaxial only
IEC958 quality: Consumer
IEC958 emphasis: off
IEC958 NonAudio: off
IEC958 sample rate: Error flag set

ADAT1: Lock
ADAT2: No Lock
ADAT3: No Lock
SPDIF: No Lock
Word Clock: No Lock
ADAT Sync: No Lock




-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Paul Davis]

>dear alsa gurus!
>i'm trying to get a rme hdsp 9652 to work, and have bad results:
>loading snd-hammerfall-mem and snd-hdsp works fine, starting jack or 
>some alsa-playback too (or at least seems to).
>but when i start alsamixer or alsactl and want to unmute the channels i 
>get massive xruns and no sound, sometimes a kernel panic.

we need a ksymoops-processed kernel panic trace.

if it makes you feel any better, i wrote a lot of the driver, and i
can't even load it right now: it locks up my system during the boot
process unconditionally.

i haven't reported it because it started doing this without any
reinstall of the module, and it was working before the reboot.

--p


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[d]

> we need a ksymoops-processed kernel panic trace.

ok, since i'm more a musician than a kernel-hacker, i don't exactly know 
what to do with the panic output.
i see EIP: 0010:[<c0280005>] and search for it in /var/log/ksymoops right?
there i find
...
c0106298 __up_wakeup
c02bfff4 csum_partial_copy_generic_Rsmp_e8aa9a96
...

so, what to do next?

> if it makes you feel any better, i wrote a lot of the driver, and i
> can't even load it right now: it locks up my system during the boot
> process unconditionally.

no, that makes me feel even more lost :(

regards
d13b




-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Paul Davis]

>ok, since i'm more a musician than a kernel-hacker, i don't exactly know 
>what to do with the panic output.
>i see EIP: 0010:[<c0280005>] and search for it in /var/log/ksymoops right?
>there i find
>...
>c0106298 __up_wakeup
>c02bfff4 csum_partial_copy_generic_Rsmp_e8aa9a96

ah. are you running on an SMP system with current ALSA CVS? if so, its
broken within the "core" of ALSA. you will need to back up to April
27th to get a working SMP version. nobody has a fix for this at this
time, despite the fact that it makes ALSA unusable on an SMP system.



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Kai Vehmanen]

On Thu, 29 May 2003, Paul Davis wrote:

>>c0106298 __up_wakeup
>>c02bfff4 csum_partial_copy_generic_Rsmp_e8aa9a96
> ah. are you running on an SMP system with current ALSA CVS? if so, its
> broken within the "core" of ALSA. you will need to back up to April
> 27th to get a working SMP version. nobody has a fix for this at this
> time, despite the fact that it makes ALSA unusable on an SMP system.

Hmm, anyway to easily and reliably reproduce the bug?

I'm running the latest ALSA and JACK CVS (updated both today) and works
fine on my SMP box (dual-celeron). And so do my other ALSA apps. And this
is not just with one card, I've tested both with es1371 and ice1712
(Delta44) and no panics yet.

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Paul Davis]

>On Thu, 29 May 2003, Paul Davis wrote:
>
>>>c0106298 __up_wakeup
>>>c02bfff4 csum_partial_copy_generic_Rsmp_e8aa9a96
>> ah. are you running on an SMP system with current ALSA CVS? if so, its
>> broken within the "core" of ALSA. you will need to back up to April
>> 27th to get a working SMP version. nobody has a fix for this at this
>> time, despite the fact that it makes ALSA unusable on an SMP system.
>
>Hmm, anyway to easily and reliably reproduce the bug?

run jack? :))

>I'm running the latest ALSA and JACK CVS (updated both today) and works
>fine on my SMP box (dual-celeron). And so do my other ALSA apps. And this
>is not just with one card, I've tested both with es1371 and ice1712
>(Delta44) and no panics yet.

i should try an update and see if its been fixed. it wasn't last week.

--p


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[d]

Paul Davis wrote:
>>>ah. are you running on an SMP system with current ALSA CVS? if so, its
>>>broken within the "core" of ALSA. you will need to back up to April
>>>27th to get a working SMP version. nobody has a fix for this at this
>>>time, despite the fact that it makes ALSA unusable on an SMP system.
>>
>>Hmm, anyway to easily and reliably reproduce the bug?

sorry for all the noise on the list.
i am running a singleprocessor system, but forgot to turn off the smp 
support in the kernel config. now - after recompiling everything- the 
kernel doesn't panic any more when i adjust the output-levels, but i 
still get nothing but silence from my card.

regards
d13b





-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Paul Davis]

>sorry for all the noise on the list.
>i am running a singleprocessor system, but forgot to turn off the smp 
>support in the kernel config. now - after recompiling everything- the 
>kernel doesn't panic any more when i adjust the output-levels, but i 
>still get nothing but silence from my card.

oh dear. now i realize that i didn't read your subject line carefully
enough. 

the hdsp 9652 driver has one major issue at this time. i have been in
lots of contact with RME to get the problem resolved, but they have
not followed through on the most recent requests. the driver is not
setting the card up so that you can hear anything, even though it does
actually run quite normally. nobody (myself, thomas or anyone else)
knows what might be wrong, and RME have told me that in theory nothing
is necessary to make this work: by default, the hdsp9652 works just
like the old hammerfall (i.e. playback stream N is routed at unity
gain to output stream N). so, we are basically waiting for RME to
respond in some way. it will probably turn out to be a one or two line
change. i wish i could tell you when it will happen, but that would be
dishonest.

--p


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Kai Vehmanen]

On Thu, 29 May 2003, Paul Davis wrote:

>>> ah. are you running on an SMP system with current ALSA CVS? if so, its
>>> broken within the "core" of ALSA. you will need to back up to April
>>Hmm, anyway to easily and reliably reproduce the bug?
> run jack? :))

Well, I've done a lot of testing during the last few days (including 
running jack :)), sometimes with both soundcards running at the same time, 
and still no oopses (system uptime now 5days). So ALSA+SMP seems to work 
fine at least on some systems.

Btw; kernel is 2.4.19 with ll-patches.

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Jaroslav Kysela]

On Sat, 31 May 2003, Kai Vehmanen wrote:

> On Thu, 29 May 2003, Paul Davis wrote:
> 
> >>> ah. are you running on an SMP system with current ALSA CVS? if so, its
> >>> broken within the "core" of ALSA. you will need to back up to April
> >>Hmm, anyway to easily and reliably reproduce the bug?
> > run jack? :))
> 
> Well, I've done a lot of testing during the last few days (including 
> running jack :)), sometimes with both soundcards running at the same time, 
> and still no oopses (system uptime now 5days). So ALSA+SMP seems to work 
> fine at least on some systems.
> 
> Btw; kernel is 2.4.19 with ll-patches.

Thanks for this report. Also many thanks for Takashi's verification of 
new pcm link code (and broken spinlocks fixes).

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Takashi Iwai]

At Sat, 31 May 2003 14:15:50 +0300 (EEST),
Kai Vehmanen wrote:
> 
> On Thu, 29 May 2003, Paul Davis wrote:
> 
> >>> ah. are you running on an SMP system with current ALSA CVS? if so, its
> >>> broken within the "core" of ALSA. you will need to back up to April
> >>Hmm, anyway to easily and reliably reproduce the bug?
> > run jack? :))
> 
> Well, I've done a lot of testing during the last few days (including 
> running jack :)), sometimes with both soundcards running at the same time, 
> and still no oopses (system uptime now 5days). So ALSA+SMP seems to work 
> fine at least on some systems.

which card are you using?
if it's the card with linked-stream feature (like trident, hdsp,
ice1712, etc.), the bug was likely solved.  if not, we still need to
investigate the behabior...


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Kai Vehmanen]

On Mon, 2 Jun 2003, Takashi Iwai wrote:

>> running jack :)), sometimes with both soundcards running at the same time, 
>> and still no oopses (system uptime now 5days). So ALSA+SMP seems to work 
> which card are you using?
> if it's the card with linked-stream feature (like trident, hdsp,
> ice1712, etc.), the bug was likely solved.  if not, we still need to
> investigate the behabior...

One Delta44/ice1712 and one ens1371.

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Jaroslav Kysela]

On Thu, 29 May 2003, Paul Davis wrote:

> >ok, since i'm more a musician than a kernel-hacker, i don't exactly know 
> >what to do with the panic output.
> >i see EIP: 0010:[<c0280005>] and search for it in /var/log/ksymoops right?
> >there i find
> >...
> >c0106298 __up_wakeup
> >c02bfff4 csum_partial_copy_generic_Rsmp_e8aa9a96
> 
> ah. are you running on an SMP system with current ALSA CVS? if so, its
> broken within the "core" of ALSA. you will need to back up to April
> 27th to get a working SMP version. nobody has a fix for this at this
> time, despite the fact that it makes ALSA unusable on an SMP system.

Anybody is willing to turn spinlock debugging in SMP kernel? I posted 
twice the guide... Edit linux/include/linux/spinlock.h:

#define DEBUG_SPINLOCKS 0       /* 0 == no debugging, 1 == maintain lock state, 2 == full debug */

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: hdsp9652+alsamixer -> kernel panic

[Paul Davis]

>On Thu, 29 May 2003, Paul Davis wrote:
>
>> >ok, since i'm more a musician than a kernel-hacker, i don't exactly know 
>> >what to do with the panic output.
>> >i see EIP: 0010:[<c0280005>] and search for it in /var/log/ksymoops right?
>> >there i find
>> >...
>> >c0106298 __up_wakeup
>> >c02bfff4 csum_partial_copy_generic_Rsmp_e8aa9a96
>> 
>> ah. are you running on an SMP system with current ALSA CVS? if so, its
>> broken within the "core" of ALSA. you will need to back up to April
>> 27th to get a working SMP version. nobody has a fix for this at this
>> time, despite the fact that it makes ALSA unusable on an SMP system.
>
>Anybody is willing to turn spinlock debugging in SMP kernel? I posted 
>twice the guide... Edit linux/include/linux/spinlock.h:

somebody already replied that this #define only has any impact in
non-SMP mode. i haven't checked if this was true, it didn't seem
unlikely.



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Single process freeze when opening capture device

[Abramo Bagnara]

Jaroslav Kysela ha scritto:
> On Thu, 29 May 2003, Abramo Bagnara wrote:
> 
> 
>>What about a "dir" field in common section of pcm configuration?
>>
>>   dir STR	# PCM allowed directions "playback", "capture", "both" (default)
> 
> 
> I'd like to solve the problem with same names, but different 
> configurations for streams.
> 
> I have an idea like:
> 
> pcm.name {
> 	... global configuration ...
> 	playback {
> 		... playback configuration ...
> 	}
> 	capture {
> 		... capture configuration ...
> 	}
> }

I'm far from convinced that to have same name for different things is a 
good idea, and in this case I'd propose to have:

pcmc.name {
}

pcmp.name {
}

then specifying different namespaces for different things.

This also permits to leave current
pcm.name {
}

unmodified (although with lower priority wrt pcmc and pcmp).

> 
> Also, we have copy of configuration for each open which is used for 
> run-time evaluation. I think that we may pass from the open code some more 
> information and use some {} region as data caching:
> 
> private {	# reserved for internal data only, warn and ignore if user defines it
> 	direction playback
> 	ctl_cache_handle 0x%p		# cache ctl handle for runtime evaluation
> 	... etc, etc ...
> }
> 
> We may add condition (if - else) evaluation functions to runtime parsing 
> which can test the contents of private variables. Now, we have same driver 
> with different chip revisions which add/remove some features (mainly 
> controls) and we need to test them to behave correctly.
> 
> Also, the first proposal requires to change all plugins, the later will 
> rewrite the configuration at run-time, so no changes are required for 
> plugins.

I've reread many times this last part but I'm unable to understand 
what's your idea. Can you rephrase?

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Single process freeze when opening capture device

[Takashi Iwai]

At Thu, 29 May 2003 15:13:11 +0200,
Abramo Bagnara wrote:
> 
> Jaroslav Kysela ha scritto:
> > On Thu, 29 May 2003, Abramo Bagnara wrote:
> > 
> > 
> >>What about a "dir" field in common section of pcm configuration?
> >>
> >>   dir STR	# PCM allowed directions "playback", "capture", "both" (default)
> > 
> > 
> > I'd like to solve the problem with same names, but different 
> > configurations for streams.
> > 
> > I have an idea like:
> > 
> > pcm.name {
> > 	... global configuration ...
> > 	playback {
> > 		... playback configuration ...
> > 	}
> > 	capture {
> > 		... capture configuration ...
> > 	}
> > }
> 
> I'm far from convinced that to have same name for different things is a 
> good idea, and in this case I'd propose to have:
> 
> pcmc.name {
> }
> 
> pcmp.name {
> }
> 
> then specifying different namespaces for different things.
> 
> This also permits to leave current
> pcm.name {
> }
> 
> unmodified (although with lower priority wrt pcmc and pcmp).

i would accept both ideas.

IIRC, the pcm is looked up through the definition in
/usr/share/alsa/alsa.conf, so if we have pcmc and pcmp definitions,
we'll need to rewrite (add) these look-up, too?


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Single process freeze when opening capture device

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> 
> 
> It is limit of current alsa-lib configuration. We cannot distinct playback
> and capture. But I am not sure, if returning an error helps you
> (surround40 configuration is NOT valid for emu10k1). I suggest to fix jack
> to allow different names for playback and capture with different count of
> channels.
> 
> 						Jaroslav
> 
Surround40 playback seems to work on my SB Live emu10k1.
Some SB Live cards have 2 stereo audio inputs, so in theory they should 
be able to do Surround40 capture as well.
Can the SB Live do 4 channel full duplex, or is there another factor 
involved.

Cheers
James



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Single process freeze when opening capture device

[Jaroslav Kysela]

On Thu, 29 May 2003, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
> > 
> > 
> > It is limit of current alsa-lib configuration. We cannot distinct playback
> > and capture. But I am not sure, if returning an error helps you
> > (surround40 configuration is NOT valid for emu10k1). I suggest to fix jack
> > to allow different names for playback and capture with different count of
> > channels.
> > 
> > 						Jaroslav
> > 
> Surround40 playback seems to work on my SB Live emu10k1.
> Some SB Live cards have 2 stereo audio inputs, so in theory they should 
> be able to do Surround40 capture as well.
> Can the SB Live do 4 channel full duplex, or is there another factor 
> involved.

The multichannel capture must be implemented using the FX DSP code (like 
raw S/PDIF). The standard capture device for emu10k1 can handle only 
stereo stream.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5