Problem with multiopen on SB Audigy 2

Problem with multiopen on SB Audigy 2

[James Courtier-Dutton]

I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and 
card 1 is a SB Audigy2

Playing two streams at once on device "front:1" works: -
aplay -D front:1 filename.wav
aplay -D front:1 filename.wav
So, this is playing two files to the SB Audigy2 front speakers.
I can hear the two files being mixed together and output together to a 
single set of speakers.

Playing two streams at once on device "rear:1" fails: -
aplay -D rear:1 filename.wav
aplay -D rear:1 filename.wav
So, this is trying to play two files to the SB Audigy2 rear speakers.

The first files comes out of the rear speakers, but the output from the 
second aplay command fails with: -

bash-2.05b# aplay -D rear:1 filename.wav
Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100 
Hz, Stereo
ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
aplay: set_params:876: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (125011 125012)
PERIOD_SIZE: 5513
PERIOD_BYTES: 22052
PERIODS: 2
BUFFER_TIME: (250022 250023)
BUFFER_SIZE: 11026
BUFFER_BYTES: 44104
TICK_TIME: 1000

Can you explain why this might be happening?

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Takashi Iwai]

At Tue, 07 Oct 2003 18:00:22 +0100,
James Courtier-Dutton wrote:
> 
> I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and 
> card 1 is a SB Audigy2
> 
> Playing two streams at once on device "front:1" works: -
> aplay -D front:1 filename.wav
> aplay -D front:1 filename.wav
> So, this is playing two files to the SB Audigy2 front speakers.
> I can hear the two files being mixed together and output together to a 
> single set of speakers.
> 
> Playing two streams at once on device "rear:1" fails: -
> aplay -D rear:1 filename.wav
> aplay -D rear:1 filename.wav
> So, this is trying to play two files to the SB Audigy2 rear speakers.
> 
> The first files comes out of the rear speakers, but the output from the 
> second aplay command fails with: -
> 
> bash-2.05b# aplay -D rear:1 filename.wav
> Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100 
> Hz, Stereo
> ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
> aplay: set_params:876: Unable to install hw params:
> ACCESS:  RW_INTERLEAVED
> FORMAT:  S16_LE
> SUBFORMAT:  STD
> SAMPLE_BITS: 16
> FRAME_BITS: 32
> CHANNELS: 2
> RATE: 44100
> PERIOD_TIME: (125011 125012)
> PERIOD_SIZE: 5513
> PERIOD_BYTES: 22052
> PERIODS: 2
> BUFFER_TIME: (250022 250023)
> BUFFER_SIZE: 11026
> BUFFER_BYTES: 44104
> TICK_TIME: 1000
> 
> Can you explain why this might be happening?

this is because the "Wave Surround Playback Volume" control is locked
by the first rear stream.
you can find it in /usr/share/alsa/cards/Audigy2.conf.
please try to remove the lock.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela]

On Tue, 7 Oct 2003, James Courtier-Dutton wrote:

> I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and
> card 1 is a SB Audigy2
>
> Playing two streams at once on device "front:1" works: -
> aplay -D front:1 filename.wav
> aplay -D front:1 filename.wav
> So, this is playing two files to the SB Audigy2 front speakers.
> I can hear the two files being mixed together and output together to a
> single set of speakers.
>
> Playing two streams at once on device "rear:1" fails: -
> aplay -D rear:1 filename.wav
> aplay -D rear:1 filename.wav
> So, this is trying to play two files to the SB Audigy2 rear speakers.
>
> The first files comes out of the rear speakers, but the output from the
> second aplay command fails with: -
>
> bash-2.05b# aplay -D rear:1 filename.wav
> Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100
> Hz, Stereo
> ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
> aplay: set_params:876: Unable to install hw params:
> ACCESS:  RW_INTERLEAVED
> FORMAT:  S16_LE
> SUBFORMAT:  STD
> SAMPLE_BITS: 16
> FRAME_BITS: 32
> CHANNELS: 2
> RATE: 44100
> PERIOD_TIME: (125011 125012)
> PERIOD_SIZE: 5513
> PERIOD_BYTES: 22052
> PERIODS: 2
> BUFFER_TIME: (250022 250023)
> BUFFER_SIZE: 11026
> BUFFER_BYTES: 44104
> TICK_TIME: 1000
>
> Can you explain why this might be happening?

See "Wave Surround Playback Volume" control in rear definition in
alsa-lib/src/conf/cards/Audigy2.conf. This control is locked thus
the second instance is not able to get lock. I'm not sure about
the right fix now.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[James Courtier-Dutton]

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

Takashi Iwai wrote:
> At Tue, 07 Oct 2003 18:00:22 +0100,
> James Courtier-Dutton wrote:
> 
>>I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and 
>>card 1 is a SB Audigy2
>>
>>Playing two streams at once on device "front:1" works: -
>>aplay -D front:1 filename.wav
>>aplay -D front:1 filename.wav
>>So, this is playing two files to the SB Audigy2 front speakers.
>>I can hear the two files being mixed together and output together to a 
>>single set of speakers.
>>
>>Playing two streams at once on device "rear:1" fails: -
>>aplay -D rear:1 filename.wav
>>aplay -D rear:1 filename.wav
>>So, this is trying to play two files to the SB Audigy2 rear speakers.
>>
>>The first files comes out of the rear speakers, but the output from the 
>>second aplay command fails with: -
>>
>>bash-2.05b# aplay -D rear:1 filename.wav
>>Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100 
>>Hz, Stereo
>>ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
>>aplay: set_params:876: Unable to install hw params:
>>ACCESS:  RW_INTERLEAVED
>>FORMAT:  S16_LE
>>SUBFORMAT:  STD
>>SAMPLE_BITS: 16
>>FRAME_BITS: 32
>>CHANNELS: 2
>>RATE: 44100
>>PERIOD_TIME: (125011 125012)
>>PERIOD_SIZE: 5513
>>PERIOD_BYTES: 22052
>>PERIODS: 2
>>BUFFER_TIME: (250022 250023)
>>BUFFER_SIZE: 11026
>>BUFFER_BYTES: 44104
>>TICK_TIME: 1000
>>
>>Can you explain why this might be happening?
> 
> 
> this is because the "Wave Surround Playback Volume" control is locked
> by the first rear stream.
> you can find it in /usr/share/alsa/cards/Audigy2.conf.
> please try to remove the lock.
> 
> 
> Takashi
> 
Thanks that fixed the problem.
Please see attached patch files, for the SB Live and Audigy2, both of 
which have been tested.

Cheers
James

[-- Attachment #2: Audigy2-rear-multiopen-fix.diff --]
[-- Type: text/plain, Size: 369 bytes --]

--- Audigy2.conf.org	2003-10-07 23:07:43.642213872 +0100
+++ Audigy2.conf	2003-10-07 23:13:48.954677936 +0100
@@ -31,12 +31,6 @@
 		type ctl_elems
 		hook_args [
 			{
-				name "Wave Surround Playback Volume"
-				preserve true
-				lock true
-				value [ 0 0 ]
-			}
-			{
 				name "EMU10K1 PCM Send Volume"
 				index { @func private_pcm_subdevice }
 				lock true

[-- Attachment #3: emu10k1-rear-multiopen-fix.diff --]
[-- Type: text/plain, Size: 369 bytes --]

--- EMU10K1.conf.org	2003-10-07 23:13:20.972931808 +0100
+++ EMU10K1.conf	2003-10-07 23:13:31.115389920 +0100
@@ -31,12 +31,6 @@
 		type ctl_elems
 		hook_args [
 			{
-				name "Wave Surround Playback Volume"
-				preserve true
-				lock true
-				value [ 0 0 ]
-			}
-			{
 				name "EMU10K1 PCM Send Volume"
 				index { @func private_pcm_subdevice }
 				lock true

Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela]

On Tue, 7 Oct 2003, James Courtier-Dutton wrote:

> Takashi Iwai wrote:
> > At Tue, 07 Oct 2003 18:00:22 +0100,
> > James Courtier-Dutton wrote:
> >
> >>I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and
> >>card 1 is a SB Audigy2
> >>
> >>Playing two streams at once on device "front:1" works: -
> >>aplay -D front:1 filename.wav
> >>aplay -D front:1 filename.wav
> >>So, this is playing two files to the SB Audigy2 front speakers.
> >>I can hear the two files being mixed together and output together to a
> >>single set of speakers.
> >>
> >>Playing two streams at once on device "rear:1" fails: -
> >>aplay -D rear:1 filename.wav
> >>aplay -D rear:1 filename.wav
> >>So, this is trying to play two files to the SB Audigy2 rear speakers.
> >>
> >>The first files comes out of the rear speakers, but the output from the
> >>second aplay command fails with: -
> >>
> >>bash-2.05b# aplay -D rear:1 filename.wav
> >>Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100
> >>Hz, Stereo
> >>ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
> >>aplay: set_params:876: Unable to install hw params:
> >>ACCESS:  RW_INTERLEAVED
> >>FORMAT:  S16_LE
> >>SUBFORMAT:  STD
> >>SAMPLE_BITS: 16
> >>FRAME_BITS: 32
> >>CHANNELS: 2
> >>RATE: 44100
> >>PERIOD_TIME: (125011 125012)
> >>PERIOD_SIZE: 5513
> >>PERIOD_BYTES: 22052
> >>PERIODS: 2
> >>BUFFER_TIME: (250022 250023)
> >>BUFFER_SIZE: 11026
> >>BUFFER_BYTES: 44104
> >>TICK_TIME: 1000
> >>
> >>Can you explain why this might be happening?
> >
> >
> > this is because the "Wave Surround Playback Volume" control is locked
> > by the first rear stream.
> > you can find it in /usr/share/alsa/cards/Audigy2.conf.
> > please try to remove the lock.
> >
> >
> > Takashi
> >
> Thanks that fixed the problem.
> Please see attached patch files, for the SB Live and Audigy2, both of
> which have been tested.

Yes, but the question is, if we want this behaviour. We expect that the
rear channel will go only via rear speakers thus setting of Wave Surround
Volume is required.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Takashi Iwai]

At Wed, 8 Oct 2003 13:08:38 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 7 Oct 2003, James Courtier-Dutton wrote:
> 
> > Takashi Iwai wrote:
> > > At Tue, 07 Oct 2003 18:00:22 +0100,
> > > James Courtier-Dutton wrote:
> > >
> > >>I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and
> > >>card 1 is a SB Audigy2
> > >>
> > >>Playing two streams at once on device "front:1" works: -
> > >>aplay -D front:1 filename.wav
> > >>aplay -D front:1 filename.wav
> > >>So, this is playing two files to the SB Audigy2 front speakers.
> > >>I can hear the two files being mixed together and output together to a
> > >>single set of speakers.
> > >>
> > >>Playing two streams at once on device "rear:1" fails: -
> > >>aplay -D rear:1 filename.wav
> > >>aplay -D rear:1 filename.wav
> > >>So, this is trying to play two files to the SB Audigy2 rear speakers.
> > >>
> > >>The first files comes out of the rear speakers, but the output from the
> > >>second aplay command fails with: -
> > >>
> > >>bash-2.05b# aplay -D rear:1 filename.wav
> > >>Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100
> > >>Hz, Stereo
> > >>ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
> > >>aplay: set_params:876: Unable to install hw params:
> > >>ACCESS:  RW_INTERLEAVED
> > >>FORMAT:  S16_LE
> > >>SUBFORMAT:  STD
> > >>SAMPLE_BITS: 16
> > >>FRAME_BITS: 32
> > >>CHANNELS: 2
> > >>RATE: 44100
> > >>PERIOD_TIME: (125011 125012)
> > >>PERIOD_SIZE: 5513
> > >>PERIOD_BYTES: 22052
> > >>PERIODS: 2
> > >>BUFFER_TIME: (250022 250023)
> > >>BUFFER_SIZE: 11026
> > >>BUFFER_BYTES: 44104
> > >>TICK_TIME: 1000
> > >>
> > >>Can you explain why this might be happening?
> > >
> > >
> > > this is because the "Wave Surround Playback Volume" control is locked
> > > by the first rear stream.
> > > you can find it in /usr/share/alsa/cards/Audigy2.conf.
> > > please try to remove the lock.
> > >
> > >
> > > Takashi
> > >
> > Thanks that fixed the problem.
> > Please see attached patch files, for the SB Live and Audigy2, both of
> > which have been tested.
> 
> Yes, but the question is, if we want this behaviour. We expect that the
> rear channel will go only via rear speakers thus setting of Wave Surround
> Volume is required.

but the signals from "rear" pcm stream should come in fact only from
the rear channels, regardless of "Wave Surround Playback Volume",
because it sets max send-volume to FX bus 2/3, and zero to others.

setting "Wave Surround Playback" would allow other pcm streams to
route the front signals to the surround, but it's a user's choice.
i don't think this exclusive behavior is necessary.


or am i missing something?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela]

On Wed, 8 Oct 2003, Takashi Iwai wrote:

> At Wed, 8 Oct 2003 13:08:38 +0200 (CEST),
> Jaroslav wrote:
> >
> > On Tue, 7 Oct 2003, James Courtier-Dutton wrote:
> >
> > > Takashi Iwai wrote:
> > > > At Tue, 07 Oct 2003 18:00:22 +0100,
> > > > James Courtier-Dutton wrote:
> > > >
> > > >>I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and
> > > >>card 1 is a SB Audigy2
> > > >>
> > > >>Playing two streams at once on device "front:1" works: -
> > > >>aplay -D front:1 filename.wav
> > > >>aplay -D front:1 filename.wav
> > > >>So, this is playing two files to the SB Audigy2 front speakers.
> > > >>I can hear the two files being mixed together and output together to a
> > > >>single set of speakers.
> > > >>
> > > >>Playing two streams at once on device "rear:1" fails: -
> > > >>aplay -D rear:1 filename.wav
> > > >>aplay -D rear:1 filename.wav
> > > >>So, this is trying to play two files to the SB Audigy2 rear speakers.
> > > >>
> > > >>The first files comes out of the rear speakers, but the output from the
> > > >>second aplay command fails with: -
> > > >>
> > > >>bash-2.05b# aplay -D rear:1 filename.wav
> > > >>Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100
> > > >>Hz, Stereo
> > > >>ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
> > > >>aplay: set_params:876: Unable to install hw params:
> > > >>ACCESS:  RW_INTERLEAVED
> > > >>FORMAT:  S16_LE
> > > >>SUBFORMAT:  STD
> > > >>SAMPLE_BITS: 16
> > > >>FRAME_BITS: 32
> > > >>CHANNELS: 2
> > > >>RATE: 44100
> > > >>PERIOD_TIME: (125011 125012)
> > > >>PERIOD_SIZE: 5513
> > > >>PERIOD_BYTES: 22052
> > > >>PERIODS: 2
> > > >>BUFFER_TIME: (250022 250023)
> > > >>BUFFER_SIZE: 11026
> > > >>BUFFER_BYTES: 44104
> > > >>TICK_TIME: 1000
> > > >>
> > > >>Can you explain why this might be happening?
> > > >
> > > >
> > > > this is because the "Wave Surround Playback Volume" control is locked
> > > > by the first rear stream.
> > > > you can find it in /usr/share/alsa/cards/Audigy2.conf.
> > > > please try to remove the lock.
> > > >
> > > >
> > > > Takashi
> > > >
> > > Thanks that fixed the problem.
> > > Please see attached patch files, for the SB Live and Audigy2, both of
> > > which have been tested.
> >
> > Yes, but the question is, if we want this behaviour. We expect that the
> > rear channel will go only via rear speakers thus setting of Wave Surround
> > Volume is required.
>
> but the signals from "rear" pcm stream should come in fact only from
> the rear channels, regardless of "Wave Surround Playback Volume",
> because it sets max send-volume to FX bus 2/3, and zero to others.
>
> setting "Wave Surround Playback" would allow other pcm streams to
> route the front signals to the surround, but it's a user's choice.
> i don't think this exclusive behavior is necessary.
>
>
> or am i missing something?

Yes, my idea was to route signal from stereo applications to all channels,
but if DVD (or other 4+.0+ format) is used, then use channels
independently. It appears that James is trying to do something
non-standard (perhaps playing two DVDs simultaneously), so I am not sure,
if we should have these things in our configurations.

It's something like "auto" stuff, but I would like to avoid user
confusion.

Anyway, users are already confused with emu10k1+ mixers, so we have to do
things more simple.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Takashi Iwai]

At Wed, 8 Oct 2003 15:49:48 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 8 Oct 2003, Takashi Iwai wrote:
> 
> > At Wed, 8 Oct 2003 13:08:38 +0200 (CEST),
> > Jaroslav wrote:
> > >
> > > On Tue, 7 Oct 2003, James Courtier-Dutton wrote:
> > >
> > > > Takashi Iwai wrote:
> > > > > At Tue, 07 Oct 2003 18:00:22 +0100,
> > > > > James Courtier-Dutton wrote:
> > > > >
> > > > >>I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and
> > > > >>card 1 is a SB Audigy2
> > > > >>
> > > > >>Playing two streams at once on device "front:1" works: -
> > > > >>aplay -D front:1 filename.wav
> > > > >>aplay -D front:1 filename.wav
> > > > >>So, this is playing two files to the SB Audigy2 front speakers.
> > > > >>I can hear the two files being mixed together and output together to a
> > > > >>single set of speakers.
> > > > >>
> > > > >>Playing two streams at once on device "rear:1" fails: -
> > > > >>aplay -D rear:1 filename.wav
> > > > >>aplay -D rear:1 filename.wav
> > > > >>So, this is trying to play two files to the SB Audigy2 rear speakers.
> > > > >>
> > > > >>The first files comes out of the rear speakers, but the output from the
> > > > >>second aplay command fails with: -
> > > > >>
> > > > >>bash-2.05b# aplay -D rear:1 filename.wav
> > > > >>Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100
> > > > >>Hz, Stereo
> > > > >>ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
> > > > >>aplay: set_params:876: Unable to install hw params:
> > > > >>ACCESS:  RW_INTERLEAVED
> > > > >>FORMAT:  S16_LE
> > > > >>SUBFORMAT:  STD
> > > > >>SAMPLE_BITS: 16
> > > > >>FRAME_BITS: 32
> > > > >>CHANNELS: 2
> > > > >>RATE: 44100
> > > > >>PERIOD_TIME: (125011 125012)
> > > > >>PERIOD_SIZE: 5513
> > > > >>PERIOD_BYTES: 22052
> > > > >>PERIODS: 2
> > > > >>BUFFER_TIME: (250022 250023)
> > > > >>BUFFER_SIZE: 11026
> > > > >>BUFFER_BYTES: 44104
> > > > >>TICK_TIME: 1000
> > > > >>
> > > > >>Can you explain why this might be happening?
> > > > >
> > > > >
> > > > > this is because the "Wave Surround Playback Volume" control is locked
> > > > > by the first rear stream.
> > > > > you can find it in /usr/share/alsa/cards/Audigy2.conf.
> > > > > please try to remove the lock.
> > > > >
> > > > >
> > > > > Takashi
> > > > >
> > > > Thanks that fixed the problem.
> > > > Please see attached patch files, for the SB Live and Audigy2, both of
> > > > which have been tested.
> > >
> > > Yes, but the question is, if we want this behaviour. We expect that the
> > > rear channel will go only via rear speakers thus setting of Wave Surround
> > > Volume is required.
> >
> > but the signals from "rear" pcm stream should come in fact only from
> > the rear channels, regardless of "Wave Surround Playback Volume",
> > because it sets max send-volume to FX bus 2/3, and zero to others.
> >
> > setting "Wave Surround Playback" would allow other pcm streams to
> > route the front signals to the surround, but it's a user's choice.
> > i don't think this exclusive behavior is necessary.
> >
> >
> > or am i missing something?
> 
> Yes, my idea was to route signal from stereo applications to all channels,
> but if DVD (or other 4+.0+ format) is used, then use channels
> independently. It appears that James is trying to do something
> non-standard (perhaps playing two DVDs simultaneously), so I am not sure,
> if we should have these things in our configurations.
> 
> It's something like "auto" stuff, but I would like to avoid user
> confusion.

hmm, now i see the problem.  i think disabling "wave surround, center,
lfe" doesn't belong to the rear or center/lfe pcm, but it's necessary
for front pcm.  or even better if we have FX bus bypassing these
duplications.

> Anyway, users are already confused with emu10k1+ mixers, so we have to do
> things more simple.

yep, i'd like to see the new design of the routing/volume.

at least, it'd be nice to have:

- a new real "master" volume for all channels
- ac97 master -> front
  ac97 pcm    -> front pcm ?
- bypass the duplication of front signals (other FX bus?)
- hide "emu10k1*" stuffs from alsamixer (a new flag?)


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela]

On Wed, 8 Oct 2003, Takashi Iwai wrote:

> > but if DVD (or other 4+.0+ format) is used, then use channels
> > independently. It appears that James is trying to do something
> > non-standard (perhaps playing two DVDs simultaneously), so I am not sure,
> > if we should have these things in our configurations.
> >
> > It's something like "auto" stuff, but I would like to avoid user
> > confusion.
>
> hmm, now i see the problem.  i think disabling "wave surround, center,
> lfe" doesn't belong to the rear or center/lfe pcm, but it's necessary
> for front pcm.  or even better if we have FX bus bypassing these
> duplications.

Yes, new FX bus will solve it, but on plain EMU10K1 chips, we're running
out of GPRs.

> > Anyway, users are already confused with emu10k1+ mixers, so we have to do
> > things more simple.
>
> yep, i'd like to see the new design of the routing/volume.
>
> at least, it'd be nice to have:
>
> - a new real "master" volume for all channels

I'm still not sure, if we should handle these things in the driver.
Hardware is not designed in this way and we should describe hardware
in the driver as most accurate as we can.

> - ac97 master -> front
>   ac97 pcm    -> front pcm ?
> - bypass the duplication of front signals (other FX bus?)

Yes, it looks good.

> - hide "emu10k1*" stuffs from alsamixer (a new flag?)

I vote to leave things asis for this case and wait for new mixer APIs.
Then we can extend the alsamixer for new APIs to handle standard (ordinary
;-) behaviour for normal users.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Takashi Iwai]

At Wed, 8 Oct 2003 16:24:33 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 8 Oct 2003, Takashi Iwai wrote:
> 
> > > but if DVD (or other 4+.0+ format) is used, then use channels
> > > independently. It appears that James is trying to do something
> > > non-standard (perhaps playing two DVDs simultaneously), so I am not sure,
> > > if we should have these things in our configurations.
> > >
> > > It's something like "auto" stuff, but I would like to avoid user
> > > confusion.
> >
> > hmm, now i see the problem.  i think disabling "wave surround, center,
> > lfe" doesn't belong to the rear or center/lfe pcm, but it's necessary
> > for front pcm.  or even better if we have FX bus bypassing these
> > duplications.
> 
> Yes, new FX bus will solve it, but on plain EMU10K1 chips, we're running
> out of GPRs.

grrr...

> > > Anyway, users are already confused with emu10k1+ mixers, so we have to do
> > > things more simple.
> >
> > yep, i'd like to see the new design of the routing/volume.
> >
> > at least, it'd be nice to have:
> >
> > - a new real "master" volume for all channels
> 
> I'm still not sure, if we should handle these things in the driver.
> Hardware is not designed in this way and we should describe hardware
> in the driver as most accurate as we can.
 
IMO, the master volume is a feature we mostly need.
in the case of emu10k1, it's much easier to implement this on the
driver (as a digital attenuator) rather than implementing it outside
the kernel space (except for the lack of GPR space).


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela]

On Wed, 8 Oct 2003, Takashi Iwai wrote:

> > I'm still not sure, if we should handle these things in the driver.
> > Hardware is not designed in this way and we should describe hardware
> > in the driver as most accurate as we can.
>
> IMO, the master volume is a feature we mostly need.
> in the case of emu10k1, it's much easier to implement this on the
> driver (as a digital attenuator) rather than implementing it outside
> the kernel space (except for the lack of GPR space).

Ok, but add more channels to "Master" so we have still a chance to control
values independently.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Problem with multiopen on SB Audigy 2

[Takashi Iwai]

At Wed, 8 Oct 2003 16:44:02 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 8 Oct 2003, Takashi Iwai wrote:
> 
> > > I'm still not sure, if we should handle these things in the driver.
> > > Hardware is not designed in this way and we should describe hardware
> > > in the driver as most accurate as we can.
> >
> > IMO, the master volume is a feature we mostly need.
> > in the case of emu10k1, it's much easier to implement this on the
> > driver (as a digital attenuator) rather than implementing it outside
> > the kernel space (except for the lack of GPR space).
> 
> Ok, but add more channels to "Master" so we have still a chance to control
> values independently.

now i'm thinking of a hierarchy like

	master (mono?)
	
	front(l/r)  rear(l/r) center/lfe ...
	
	outputs...

the advantage is that you can adjust all volumes with a single
control.  adjusting the level for each channel is done by the volumes
below it.  there is still a problem that the sensitivity is different
between front and surround volumes (the former is ac97 and the latter
is the digital attenuation).  perhaps it's solved when we introduce dB
hints.

or, yes, instead of the top master, we merge all the lower layers as
the master volume (either multi-channels or "master front", "master
rear", etc.)

perhaps we should create some templates of basic mixer designs suited
to different hardware implementations.  the confusion we're facing now
seems to come from the different implementation even though the same
control name is used.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela]

On Wed, 8 Oct 2003, Takashi Iwai wrote:

> At Wed, 8 Oct 2003 16:44:02 +0200 (CEST),
> Jaroslav wrote:
> >
> > On Wed, 8 Oct 2003, Takashi Iwai wrote:
> >
> > > > I'm still not sure, if we should handle these things in the driver.
> > > > Hardware is not designed in this way and we should describe hardware
> > > > in the driver as most accurate as we can.
> > >
> > > IMO, the master volume is a feature we mostly need.
> > > in the case of emu10k1, it's much easier to implement this on the
> > > driver (as a digital attenuator) rather than implementing it outside
> > > the kernel space (except for the lack of GPR space).
> >
> > Ok, but add more channels to "Master" so we have still a chance to control
> > values independently.
>
> now i'm thinking of a hierarchy like
>
> 	master (mono?)
>
> 	front(l/r)  rear(l/r) center/lfe ...
>
> 	outputs...
>
> the advantage is that you can adjust all volumes with a single
> control.  adjusting the level for each channel is done by the volumes
> below it.  there is still a problem that the sensitivity is different
> between front and surround volumes (the former is ac97 and the latter
> is the digital attenuation).  perhaps it's solved when we introduce dB
> hints.
>
> or, yes, instead of the top master, we merge all the lower layers as
> the master volume (either multi-channels or "master front", "master
> rear", etc.)
>
> perhaps we should create some templates of basic mixer designs suited
> to different hardware implementations.  the confusion we're facing now
> seems to come from the different implementation even though the same
> control name is used.

Yes, but again, why to try to solve these things in the kernel space?
There is no point to do it there and also we can modify simple API to use
hints written in lisp to handle the special cases - like covered in
this discussion.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Problem with multiopen on SB Audigy 2

[Takashi Iwai]

At Wed, 8 Oct 2003 17:44:41 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 8 Oct 2003, Takashi Iwai wrote:
> 
> > At Wed, 8 Oct 2003 16:44:02 +0200 (CEST),
> > Jaroslav wrote:
> > >
> > > On Wed, 8 Oct 2003, Takashi Iwai wrote:
> > >
> > > > > I'm still not sure, if we should handle these things in the driver.
> > > > > Hardware is not designed in this way and we should describe hardware
> > > > > in the driver as most accurate as we can.
> > > >
> > > > IMO, the master volume is a feature we mostly need.
> > > > in the case of emu10k1, it's much easier to implement this on the
> > > > driver (as a digital attenuator) rather than implementing it outside
> > > > the kernel space (except for the lack of GPR space).
> > >
> > > Ok, but add more channels to "Master" so we have still a chance to control
> > > values independently.
> >
> > now i'm thinking of a hierarchy like
> >
> > 	master (mono?)
> >
> > 	front(l/r)  rear(l/r) center/lfe ...
> >
> > 	outputs...
> >
> > the advantage is that you can adjust all volumes with a single
> > control.  adjusting the level for each channel is done by the volumes
> > below it.  there is still a problem that the sensitivity is different
> > between front and surround volumes (the former is ac97 and the latter
> > is the digital attenuation).  perhaps it's solved when we introduce dB
> > hints.
> >
> > or, yes, instead of the top master, we merge all the lower layers as
> > the master volume (either multi-channels or "master front", "master
> > rear", etc.)
> >
> > perhaps we should create some templates of basic mixer designs suited
> > to different hardware implementations.  the confusion we're facing now
> > seems to come from the different implementation even though the same
> > control name is used.
> 
> Yes, but again, why to try to solve these things in the kernel space?
> There is no point to do it there and also we can modify simple API to use
> hints written in lisp to handle the special cases - like covered in
> this discussion.

the template i meant above is the basic designs of control naming, and
i don't mean that this is the kernel issue.  (well, in the case of
"master" volume, we cannot handle it simply by abstraction but need a
new control, though.)

i believe it's just a question which is easier to implement.
i agree that almost all cases can be solved by a higher abstraction,
and i prefer that, too.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela]

On Wed, 8 Oct 2003, Takashi Iwai wrote:

> At Wed, 8 Oct 2003 17:44:41 +0200 (CEST),
> Jaroslav wrote:
> >
> > On Wed, 8 Oct 2003, Takashi Iwai wrote:
> >
> > > At Wed, 8 Oct 2003 16:44:02 +0200 (CEST),
> > > Jaroslav wrote:
> > > >
> > > > On Wed, 8 Oct 2003, Takashi Iwai wrote:
> > > >
> > > > > > I'm still not sure, if we should handle these things in the driver.
> > > > > > Hardware is not designed in this way and we should describe hardware
> > > > > > in the driver as most accurate as we can.
> > > > >
> > > > > IMO, the master volume is a feature we mostly need.
> > > > > in the case of emu10k1, it's much easier to implement this on the
> > > > > driver (as a digital attenuator) rather than implementing it outside
> > > > > the kernel space (except for the lack of GPR space).
> > > >
> > > > Ok, but add more channels to "Master" so we have still a chance to control
> > > > values independently.
> > >
> > > now i'm thinking of a hierarchy like
> > >
> > > 	master (mono?)
> > >
> > > 	front(l/r)  rear(l/r) center/lfe ...
> > >
> > > 	outputs...
> > >
> > > the advantage is that you can adjust all volumes with a single
> > > control.  adjusting the level for each channel is done by the volumes
> > > below it.  there is still a problem that the sensitivity is different
> > > between front and surround volumes (the former is ac97 and the latter
> > > is the digital attenuation).  perhaps it's solved when we introduce dB
> > > hints.
> > >
> > > or, yes, instead of the top master, we merge all the lower layers as
> > > the master volume (either multi-channels or "master front", "master
> > > rear", etc.)
> > >
> > > perhaps we should create some templates of basic mixer designs suited
> > > to different hardware implementations.  the confusion we're facing now
> > > seems to come from the different implementation even though the same
> > > control name is used.
> >
> > Yes, but again, why to try to solve these things in the kernel space?
> > There is no point to do it there and also we can modify simple API to use
> > hints written in lisp to handle the special cases - like covered in
> > this discussion.
>
> the template i meant above is the basic designs of control naming, and
> i don't mean that this is the kernel issue.  (well, in the case of
> "master" volume, we cannot handle it simply by abstraction but need a
> new control, though.)
>
> i believe it's just a question which is easier to implement.
> i agree that almost all cases can be solved by a higher abstraction,
> and i prefer that, too.

Yes, I think that we might use the kernel to create the "user defined"
controls which can be created from the user space. In this case, we can
nicely do all kinds of abstractions in the user space.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Problem with multiopen on SB Audigy 2 / Mixer setting.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Wed, 8 Oct 2003, Takashi Iwai wrote:
> 
> 
>>At Wed, 8 Oct 2003 13:08:38 +0200 (CEST),
>>Jaroslav wrote:
>>
>>>On Tue, 7 Oct 2003, James Courtier-Dutton wrote:
>>>
>>>
>>>>Takashi Iwai wrote:
>>>>
>>>>>At Tue, 07 Oct 2003 18:00:22 +0100,
>>>>>James Courtier-Dutton wrote:
>>>>>
>>>>>
>>>>>>I have 2 sound cards, card 0 is the motherboard intel/alc650 one, and
>>>>>>card 1 is a SB Audigy2
>>>>>>
>>>>>>Playing two streams at once on device "front:1" works: -
>>>>>>aplay -D front:1 filename.wav
>>>>>>aplay -D front:1 filename.wav
>>>>>>So, this is playing two files to the SB Audigy2 front speakers.
>>>>>>I can hear the two files being mixed together and output together to a
>>>>>>single set of speakers.
>>>>>>
>>>>>>Playing two streams at once on device "rear:1" fails: -
>>>>>>aplay -D rear:1 filename.wav
>>>>>>aplay -D rear:1 filename.wav
>>>>>>So, this is trying to play two files to the SB Audigy2 rear speakers.
>>>>>>
>>>>>>The first files comes out of the rear speakers, but the output from the
>>>>>>second aplay command fails with: -
>>>>>>
>>>>>>bash-2.05b# aplay -D rear:1 filename.wav
>>>>>>Playing WAVE 'filename.wav' : Signed 16 bit Little Endian, Rate 44100
>>>>>>Hz, Stereo
>>>>>>ALSA lib setup.c:94:(snd_sctl_install) Cannot lock ctl elem
>>>>>>aplay: set_params:876: Unable to install hw params:
>>>>>>ACCESS:  RW_INTERLEAVED
>>>>>>FORMAT:  S16_LE
>>>>>>SUBFORMAT:  STD
>>>>>>SAMPLE_BITS: 16
>>>>>>FRAME_BITS: 32
>>>>>>CHANNELS: 2
>>>>>>RATE: 44100
>>>>>>PERIOD_TIME: (125011 125012)
>>>>>>PERIOD_SIZE: 5513
>>>>>>PERIOD_BYTES: 22052
>>>>>>PERIODS: 2
>>>>>>BUFFER_TIME: (250022 250023)
>>>>>>BUFFER_SIZE: 11026
>>>>>>BUFFER_BYTES: 44104
>>>>>>TICK_TIME: 1000
>>>>>>
>>>>>>Can you explain why this might be happening?
>>>>>
>>>>>
>>>>>this is because the "Wave Surround Playback Volume" control is locked
>>>>>by the first rear stream.
>>>>>you can find it in /usr/share/alsa/cards/Audigy2.conf.
>>>>>please try to remove the lock.
>>>>>
>>>>>
>>>>>Takashi
>>>>>
>>>>
>>>>Thanks that fixed the problem.
>>>>Please see attached patch files, for the SB Live and Audigy2, both of
>>>>which have been tested.
>>>
>>>Yes, but the question is, if we want this behaviour. We expect that the
>>>rear channel will go only via rear speakers thus setting of Wave Surround
>>>Volume is required.
>>
>>but the signals from "rear" pcm stream should come in fact only from
>>the rear channels, regardless of "Wave Surround Playback Volume",
>>because it sets max send-volume to FX bus 2/3, and zero to others.
>>
>>setting "Wave Surround Playback" would allow other pcm streams to
>>route the front signals to the surround, but it's a user's choice.
>>i don't think this exclusive behavior is necessary.
>>
>>
>>or am i missing something?
> 
> 
> Yes, my idea was to route signal from stereo applications to all channels,
> but if DVD (or other 4+.0+ format) is used, then use channels
> independently. It appears that James is trying to do something
> non-standard (perhaps playing two DVDs simultaneously), so I am not sure,
> if we should have these things in our configurations.
> 
> It's something like "auto" stuff, but I would like to avoid user
> confusion.
> 
> Anyway, users are already confused with emu10k1+ mixers, so we have to do
> things more simple.
> 
> 						Jaroslav
> 
The person who reported the "rear" issue was playing only games.
"front" had headphones plugged in, because that it is where the 
headphone amp is, and "rear" was connected to speakers. (or the other 
way arround, I don't remember).
The user was playing games so wanted sound coming out of the speakers, 
together with any backround music they wanted. (so 2 opens on speakers 
needed) and also using an application called "teamspeak", where the 
person had a set of headphones with a mic, and they could use them to 
talk to other players on their own team during play. They also wanted to 
possibly play other sound sources into the headphones at the same time.

So, basically, hardware mixing 2 sources to "front", and at the same 
time hardware mixing 2 sources to "rear", and with the help of my patch 
files, they managed to do it.

As the SB Live and Audigy2 both allow this, then I don't think we should 
prevent this sort of setup from working.

Regarding the mixers. I don't think we have to make things more simple 
exactly. We should first decide which sliders we want for playback, and 
what they should be called, and then decide how to implement them for 
each sound card. That way, the naming will be consistent, and also 
intuative to the user.

Maybe we should add the the config files config for mixer's as well as 
the current pcm config, and let alsa-lib take what hardware mixer 
controls there are, and via config files manipulate them to provide the 
standard set that we wish all cards to present.

For example (what the user sees) : -
Master (controls all output channels at once)
Front (controls volume of front speakers)
Headphone (controls volume of headphones)
Rear  (controls volume of rear speakers)
Center/LFE (controls volume of Center/LFE speakers)

If the Headphone's are linked to Front, then combine those 2 sliders.
The conversion from what the user sees, to which registers actually get 
set on the sound card, could be controlled by the config file, and 
therefore allow for Mixer name changing, adding "Front/Rear Fader" could 
all be added by the user into the config file, without any source code 
having to change.

I think that the lack of a clear "mixer view to the user" has led to 
mixer controls having non-intuitive names, and functions.

One think about the Windows mixer that I like, is that one has one 
"playback mixer view" for controlling playback of sound from PC to 
Speakers, and a totally different "recording mixer view" for when 
recording from some source back into the PC.

Also, with this "mixer config file", we might be able to add features 
like "0 db" levels, if the user so wishes.

There are already card specific config files, so having card specific 
mixer config files should not be to difficult to implement.

Cheers
James



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Problem with multiopen on SB Audigy 2

[James Courtier-Dutton]

Jaroslav Kysela wrote:
>>
>>the template i meant above is the basic designs of control naming, and
>>i don't mean that this is the kernel issue.  (well, in the case of
>>"master" volume, we cannot handle it simply by abstraction but need a
>>new control, though.)
>>
>>i believe it's just a question which is easier to implement.
>>i agree that almost all cases can be solved by a higher abstraction,
>>and i prefer that, too.
> 
> 
> Yes, I think that we might use the kernel to create the "user defined"
> controls which can be created from the user space. In this case, we can
> nicely do all kinds of abstractions in the user space.
> 
> 						Jaroslav
> 

I agree, that the less work done in kernel space the better.
I also think it is a good idea to have user space creating virtual 
controls (abstractions), but of course, the values/state given to these 
virtual controls has to be stored somewhere, and kernel space will 
probably have to store them, otherwise their state will not survive 
across application stop/start.

How would one start supporting some of the multichannel features 
availiable on some cards. E.g. surround sound 7.1 (8 channels)

I think we should take the names for the speakers from the AC3 or DTS 
specifications.
AC3 names: -
Left
Center
Right
Left Surround
Right Surround
Low Frequency Effects.

DTS names: -
Left
Center Left
Center
Center Right
Right
Surround Left1
Surround Right1
Surround Left2
Surround Right2
Rear Left
Rear Center
Rear Right
Overhead
Low Frequency Effects.

We would also need to add: -
Headphones

So, I conclude from this, that maybe we should add to the config files a 
way for the user to say what is plugged into what, and name it themselves.

Cheers
James




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela]

On Thu, 9 Oct 2003, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
> >>
> >>the template i meant above is the basic designs of control naming, and
> >>i don't mean that this is the kernel issue.  (well, in the case of
> >>"master" volume, we cannot handle it simply by abstraction but need a
> >>new control, though.)
> >>
> >>i believe it's just a question which is easier to implement.
> >>i agree that almost all cases can be solved by a higher abstraction,
> >>and i prefer that, too.
> >
> >
> > Yes, I think that we might use the kernel to create the "user defined"
> > controls which can be created from the user space. In this case, we can
> > nicely do all kinds of abstractions in the user space.
> >
> > 						Jaroslav
> >
>
> I agree, that the less work done in kernel space the better.
> I also think it is a good idea to have user space creating virtual
> controls (abstractions), but of course, the values/state given to these
> virtual controls has to be stored somewhere, and kernel space will
> probably have to store them, otherwise their state will not survive
> across application stop/start.

Yes, that's my idea, too.

> How would one start supporting some of the multichannel features
> availiable on some cards. E.g. surround sound 7.1 (8 channels)
>
> I think we should take the names for the speakers from the AC3 or DTS
> specifications.
> AC3 names: -
> Left
> Center
> Right
> Left Surround
> Right Surround
> Low Frequency Effects.
>
> DTS names: -
> Left
> Center Left
> Center
> Center Right
> Right
> Surround Left1
> Surround Right1
> Surround Left2
> Surround Right2
> Rear Left
> Rear Center
> Rear Right
> Overhead
> Low Frequency Effects.
>
> We would also need to add: -
> Headphones
>
> So, I conclude from this, that maybe we should add to the config files a
> way for the user to say what is plugged into what, and name it themselves.

Yes, that's true especially for the multichannel cards being used for
the hifi consumer audio.

I agree that we have gaps in these areas.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Problem with multiopen on SB Audigy 2

[Takashi Iwai]

At Thu, 9 Oct 2003 08:52:01 +0200,
p z oooo wrote:
> 
> And use Philips DAC on Audigy 1 instead of AC97 for front channel (
> Same volume levels as others channels, beter precision, ...).
> AC97 will be then used only for analog inputs.

could you send me a patch?  :)

ATM, the audigy card is out of my machine, so i cannot work on
that...


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Problem with multiopen on SB Audigy 2

[p z oooo]

And use Philips DAC on Audigy 1 instead of AC97 for front channel (
Same volume levels as others channels, beter precision, ...).
AC97 will be then used only for analog inputs.

Peter Zubaj



____________________________________
http://www.pobox.sk/ - spolahliva a bezpecna prevadzka





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php