Hi!
As far as I understand it, "theoretically", it should work both ways.
You still have to do it the way that the dmix device is the last device,
because the dmix plugin requires a hardware slave (AFAIK). It can't pass
the sound data to a virtual device like softvol.
Greets, Ingo
Sebastian Schäfer schrieb:
> Hi!
>
> Possibly I am wrong, but shouldn't the order of softvol and dmix be just
> the other way round, so that all the streams are mixed together and then
> routed through softvol which outputs directly on the hardware?
>
> Best regards,
> Sebastian
>
> On Di, 2007-01-09 at 17:57 +0100, Ingo Müller wrote:
>> Hi!
>>
>> Below my asoundrc file (the relevant part). The first device overwrites
>> the default device and sends all incoming data to the second device.
>> That way, most applications will just continue to work using the default
>> device. The second device is the softvol device which should add a new
>> volume control "Master". If there was no such control before, mixers
>> like KMix or alsamixer will treat the new one as the actual master
>> volume control. This device passes its data to the third device, a dmix
>> device. I need this, because my sound card does not hardware mixing.
>> (Don't consider this as the absolute truth, this is only what I think I
>> found out by trail and error ;-))
>>
>> The values like rate, period_time etc are specific to my hardware, too.
>> They may not be optimal. That solution is not complete, I think. I
>> didn't test OSS support nor capturing. I hope this helps anyway. Please
>> report back if it works for you.
>>
>> Greets, Ingo
>>
>> ----
>>
>> # first
>> pcm.!default {
>> type plug
>> slave.pcm "softvol"
>> }
>>
>> # second
>> pcm.softvol {
>> type softvol
>> slave {
>> pcm "dmix"
>> }
>> control {
>> name "Master"
>> card 0
>> }
>> }
>>
>> # third
>> pcm.dmix {
>> type dmix
>> ipc_key 1024
>> slave {
>> pcm "hw:0,0"
>> rate 48000
>> period_time 0
>> period_size 1024
>> buffer_time 0
>> buffer_size 4096
>> }
>> }
>>
>> ----
>>
>> Emilio Scalise schrieb:
>>> Could you post the asound.conf/.asoundrc file and the link to the bug
>>> report... ;-)
>>> Thanks...
>>>
>>> 2007/1/7, Ingo Müller <[EMAIL PROTECTED]>:
>>>> Hi!
>>>>
>>>> If you don't have a master volume control at all, I can help you! I had
>>>> the same problem with an CMI7012 chip. Just create a softvol control and
>>>> name it "Master". Of course, every application that uses alsa has to use
>>>> a virtual device that goes sooner or later through that softvol device.
>>>> I don't know whether this is the perfect way to do it, but it did the
>>>> job for me and I think it's cleaner than a script sounds to me.
>>>>
>>>> What I'm missing in that solution is the mute function. I already filed
>>>> a wish in the bug tracking system. Maybe you could add a note to
>>>> underline the need of such a function, if you need it, too.
>>>>
>>>> I hope that helps you.
>>>>
>>>> Greets, Ingo
>>>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Alsa-user mailing list
>> Alsa-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/alsa-user
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
