* Problem with multiopen on SB Audigy 2 @ 2003-10-07 17:00 James Courtier-Dutton 2003-10-07 17:08 ` Takashi Iwai 2003-10-07 18:02 ` Problem with multiopen on SB Audigy 2 Jaroslav Kysela 0 siblings, 2 replies; 20+ messages in thread From: James Courtier-Dutton @ 2003-10-07 17:00 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-07 17:00 Problem with multiopen on SB Audigy 2 James Courtier-Dutton @ 2003-10-07 17:08 ` Takashi Iwai 2003-10-07 22:16 ` James Courtier-Dutton 2003-10-07 18:02 ` Problem with multiopen on SB Audigy 2 Jaroslav Kysela 1 sibling, 1 reply; 20+ messages in thread From: Takashi Iwai @ 2003-10-07 17:08 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-07 17:08 ` Takashi Iwai @ 2003-10-07 22:16 ` James Courtier-Dutton 2003-10-08 11:08 ` Jaroslav Kysela 0 siblings, 1 reply; 20+ messages in thread From: James Courtier-Dutton @ 2003-10-07 22:16 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-07 22:16 ` James Courtier-Dutton @ 2003-10-08 11:08 ` Jaroslav Kysela 2003-10-08 13:42 ` Takashi Iwai 0 siblings, 1 reply; 20+ messages in thread From: Jaroslav Kysela @ 2003-10-08 11:08 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Takashi Iwai, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 11:08 ` Jaroslav Kysela @ 2003-10-08 13:42 ` Takashi Iwai 2003-10-08 13:49 ` Jaroslav Kysela 0 siblings, 1 reply; 20+ messages in thread From: Takashi Iwai @ 2003-10-08 13:42 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 13:42 ` Takashi Iwai @ 2003-10-08 13:49 ` Jaroslav Kysela 2003-10-08 14:05 ` Takashi Iwai 2003-10-08 22:36 ` Problem with multiopen on SB Audigy 2 / Mixer setting James Courtier-Dutton 0 siblings, 2 replies; 20+ messages in thread From: Jaroslav Kysela @ 2003-10-08 13:49 UTC (permalink / raw) To: Takashi Iwai; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 13:49 ` Jaroslav Kysela @ 2003-10-08 14:05 ` Takashi Iwai 2003-10-08 14:24 ` Jaroslav Kysela 2003-10-08 22:36 ` Problem with multiopen on SB Audigy 2 / Mixer setting James Courtier-Dutton 1 sibling, 1 reply; 20+ messages in thread From: Takashi Iwai @ 2003-10-08 14:05 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 14:05 ` Takashi Iwai @ 2003-10-08 14:24 ` Jaroslav Kysela 2003-10-08 14:39 ` Takashi Iwai 0 siblings, 1 reply; 20+ messages in thread From: Jaroslav Kysela @ 2003-10-08 14:24 UTC (permalink / raw) To: Takashi Iwai; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 14:24 ` Jaroslav Kysela @ 2003-10-08 14:39 ` Takashi Iwai 2003-10-08 14:44 ` Jaroslav Kysela 0 siblings, 1 reply; 20+ messages in thread From: Takashi Iwai @ 2003-10-08 14:39 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 14:39 ` Takashi Iwai @ 2003-10-08 14:44 ` Jaroslav Kysela 2003-10-08 15:00 ` Takashi Iwai 0 siblings, 1 reply; 20+ messages in thread From: Jaroslav Kysela @ 2003-10-08 14:44 UTC (permalink / raw) To: Takashi Iwai; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 14:44 ` Jaroslav Kysela @ 2003-10-08 15:00 ` Takashi Iwai 2003-10-08 15:44 ` Jaroslav Kysela 0 siblings, 1 reply; 20+ messages in thread From: Takashi Iwai @ 2003-10-08 15:00 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 15:00 ` Takashi Iwai @ 2003-10-08 15:44 ` Jaroslav Kysela 2003-10-08 15:58 ` Takashi Iwai 0 siblings, 1 reply; 20+ messages in thread From: Jaroslav Kysela @ 2003-10-08 15:44 UTC (permalink / raw) To: Takashi Iwai; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 15:44 ` Jaroslav Kysela @ 2003-10-08 15:58 ` Takashi Iwai 2003-10-08 16:27 ` Jaroslav Kysela 0 siblings, 1 reply; 20+ messages in thread From: Takashi Iwai @ 2003-10-08 15:58 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 15:58 ` Takashi Iwai @ 2003-10-08 16:27 ` Jaroslav Kysela 2003-10-09 1:14 ` James Courtier-Dutton 0 siblings, 1 reply; 20+ messages in thread From: Jaroslav Kysela @ 2003-10-08 16:27 UTC (permalink / raw) To: Takashi Iwai; +Cc: James Courtier-Dutton, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-08 16:27 ` Jaroslav Kysela @ 2003-10-09 1:14 ` James Courtier-Dutton 2003-10-09 13:13 ` Jaroslav Kysela 0 siblings, 1 reply; 20+ messages in thread From: James Courtier-Dutton @ 2003-10-09 1:14 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: Takashi Iwai, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-09 1:14 ` James Courtier-Dutton @ 2003-10-09 13:13 ` Jaroslav Kysela 0 siblings, 0 replies; 20+ messages in thread From: Jaroslav Kysela @ 2003-10-09 13:13 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Takashi Iwai, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 / Mixer setting. 2003-10-08 13:49 ` Jaroslav Kysela 2003-10-08 14:05 ` Takashi Iwai @ 2003-10-08 22:36 ` James Courtier-Dutton 1 sibling, 0 replies; 20+ messages in thread From: James Courtier-Dutton @ 2003-10-08 22:36 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: Takashi Iwai, alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-07 17:00 Problem with multiopen on SB Audigy 2 James Courtier-Dutton 2003-10-07 17:08 ` Takashi Iwai @ 2003-10-07 18:02 ` Jaroslav Kysela 1 sibling, 0 replies; 20+ messages in thread From: Jaroslav Kysela @ 2003-10-07 18:02 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 @ 2003-10-09 6:52 p z oooo 2003-10-09 13:26 ` Takashi Iwai 0 siblings, 1 reply; 20+ messages in thread From: p z oooo @ 2003-10-09 6:52 UTC (permalink / raw) To: alsa-devel; +Cc: perex, tiwai, James 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with multiopen on SB Audigy 2 2003-10-09 6:52 p z oooo @ 2003-10-09 13:26 ` Takashi Iwai 0 siblings, 0 replies; 20+ messages in thread From: Takashi Iwai @ 2003-10-09 13:26 UTC (permalink / raw) To: p z oooo; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2003-10-09 13:26 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-07 17:00 Problem with multiopen on SB Audigy 2 James Courtier-Dutton 2003-10-07 17:08 ` Takashi Iwai 2003-10-07 22:16 ` James Courtier-Dutton 2003-10-08 11:08 ` Jaroslav Kysela 2003-10-08 13:42 ` Takashi Iwai 2003-10-08 13:49 ` Jaroslav Kysela 2003-10-08 14:05 ` Takashi Iwai 2003-10-08 14:24 ` Jaroslav Kysela 2003-10-08 14:39 ` Takashi Iwai 2003-10-08 14:44 ` Jaroslav Kysela 2003-10-08 15:00 ` Takashi Iwai 2003-10-08 15:44 ` Jaroslav Kysela 2003-10-08 15:58 ` Takashi Iwai 2003-10-08 16:27 ` Jaroslav Kysela 2003-10-09 1:14 ` James Courtier-Dutton 2003-10-09 13:13 ` Jaroslav Kysela 2003-10-08 22:36 ` Problem with multiopen on SB Audigy 2 / Mixer setting James Courtier-Dutton 2003-10-07 18:02 ` Problem with multiopen on SB Audigy 2 Jaroslav Kysela 2003-10-09 6:52 p z oooo 2003-10-09 13:26 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.