Now Dmix is allegedly a good thing.
It would be nice to have to have multiple instances of sound applications all making nice at the same time without all those awkward "Device is Busy" warnings.
By all accounts read so far it as simple as implementing the correct section in the alsa.conf
a brief glimpse at my alsa.conf seems to confirm that the stubs are there for the dmix in
Code:
...
# defaults
defaults.pcm.dmix_max_periods 0
defaults.pcm.dmix_max_rate 48000
defaults.pcm.dmix_max_fornat S16_LE
...
so the next step is to see if the pcm has the dmix configured as a slave as per the instructions here:
http://www.alsa-project.org/main/index.php/Asoundrc
Quote:
dmix
These days we have a native plugin for ALSA called the dmix (direct mixing) plugin. It allows software mixing in an easy to use syntax and without the hassle of installing/understanding a new application first.
A very interesting and potentially extremely useful aspect of this plugin is using it combined with the default plugin name. In theory this means all applications that have native ALSA support will share the sound device. In practice not many applications are able to take advantage of this functionality yet. However if you have time to test and report your findings to the application developers it is worth a try:
pcm.!default {
type plug
slave.pcm "dmixer"
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:1,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
}
bindings {
0 0
1 1
}
}
ctl.dmixer {
type hw
card 0
}
(To use it with your own name just change the word !default above)
|
so that's seems relatively straightforward let's see what we have in our alsa.conf...
well there is a reference to it being instantiated but not actually configured:
pcm.dmix cards.pcm.dmix
so it looks like we will have to add the actual config to the alsa.conf either directly or indirectly via alsactl.
The intention is to leave everything that was originally installed on the device intact.
At the very least to restore it to the exact original configuration after we are done.
However since multiple application may need to use this dmix device - outside of the scope of an individual instance of an application - this would seem to need to be a system-wide and permanent change.
So next question: would the intended changes affect the operation of anything on the device currently?
No, it is simply finishing off initialising what is already instanced so in this case I think an exception can be made to the ideal of never touching system files.
Next question: How can we undo any changes we might make?
Alsactl has a store and restore facility that I will make use of to implement an "uninstall". It should be fairly trivial and actually really just a case of simply restoring the image of the original alsa.conf as opposed to any clever -changed-state-rollback wangles. Happy days there then.
More research on that to follow I think.
trying something like
[root@kindle video]#
Balsamic test.wav
(with the device internally set to "dmix")
(First the config lookup error
Code:
ALSA lib conf.c:3501:(snd_config_hook_load)
cannot stat file/directory /blah-blah/CodeSourcery/
Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/share/alsa/cards/aliases.conf
Then a reference to dmix being link to device.pcm.dmix and it not working.:
Code:
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate)
Unknown PCM cards.pcm.dmix
Can't open audio dmix: No such file or directory
If the link to the conf is fixed we get:
Code:
[root@kindle video]# ./Balsamic test.wav
ALSA lib pcm.c:7431:(snd_pcm_set_params)
Rate doesn't match (requested 44100Hz, get 0Hz)
Can't set sound parameters: Invalid argument
Which looks like it's not setup. so...
Next step. Alsactl Store and restore (and test just doing the setup by hand)