I have a very specific device on which I have a custom ALSA-Lib. This library currently works fine when using for example squeezelite or RoonBridge. The main changes have been made in pcm_params.c in the function snd_pcm_hw_param_set. However, it does not even seem like volumio uses this function, which is very unusual. Is this true?
If I am correct MPD takes control of the soundcard and ALSA. Is this indeed true?
Lastly, can i read my stdout somewhere? For example I do have some fprintf in the alsa driver which I can currently not read as I only get the node.js output.
I have indeed seen the asound.conf. I will give a short description of how my device works.
I have a device with an internal soundcard which is controlled with two clocks. One clock is 24576000Hz. The other is 11289600Hz. I can mux these clocks from the user space in Linux. This allows met to get 44.1/48/88.2/96/176.4/192Khz bit perfect without resampling. Now, what my Alsa driver does is check what clock is necessary to achieve the rate and make a kernel call to change the clock in kernel space. And then makes a user space call to the GPIO’s, which has to be a sudo call as it is in /sys/. This is quite unhandy when there are a lot of users taking control of the audio device. Lastly I completly disabled resampling in the ALSA-lib. This means you can do whatever you want in /etc/asound.conf, but it will never resample.
This does make everything very static, but that does not matter since the device does not have the ability to get any other soundcards except USB. Which does not need any resampling.
pcm.volumioOutput {
type plug
slave.pcm "volumioHw"
}
pcm.volumioHw {
type hw
card "soundcard"
}
The first problem now is that I have a type plug in asound.conf. Which I do not want. I want to bypass volumioOutput. I can however not find the option to how I should do this. I read the documentation regarding ALSA, but that only deals with the append of multiroom. I can not find where I could possibly change the above so it becomes static. Since volumio changes asound at every startup this makes it quite a problem as I think pulse is trying to get plugins which are not available since i disabled them entirely. Do you have any idea where this pre asound.conf comes from?
I think that is more of a design choice. In my opinion the GPIO should be changed by ALSA-LIB (libasound2) in user space since this library is the only one who knows the true rate of the current playback, otherwise you would make syscalls to make this change, which is essentially the same but then moved to a different place. The kernel never knows the true rate of a playback as it is just given by ALSA-LIB to kernel. If a song at 48Khz is resampled to 8Khz in userspace the kernel will never know the original playback was 48Khz.
I can also not shield the GPIOs from user space as it are I2C expanders which take control of for example headphone input amplifier output etc.
Like I said, Volumio is the first software I come accross that does not properly work on as it does not seem to use snd_pcm_hw_param_set at every new playback, which I have not seen before.
edit: I believe I do not even know which GPIO to touch in kernel space as it is dynamically added at boot as it is on an I2C expander.
Hello, I rebound on this specific point (resetting asound.conf at every startup) as it also prevent me from doing some testing to force ADC hardware sample rate (see here Analog input sampling rate and bit depth)
If anyone knows hot to disable this asound.conf reinitialisation, I would be super happy to know .
The asound.conf is actually hardcoded in /Volumio/app/plugins/output/alsa_controller/index.js. The mpd.conf is not entirely hardcoded but some aspects are hard coded into the code in /Volumio/app/plugins/music_service/mpd/index.js. You will also find the template in this MPD folder to which the index.js of MPD writes to.
Basically there is no easy way to change the asound.conf. Also, the documentation says plugins are not allowed to change asounf.conf anymore which seems to contradict with the documentation provided which says otherwise when using Volumio 3 or higher. I also do not think it’s very convenient that the asound.conf has a lot of slaves which always lead to the same soundcard. I also do not entirely understand the hw plug.
However, with these feedback I also want to speak out that’s appreciate the work of Volumio as it is free software which is open source.
I managed to fix my issue anyways and get my driver to work correctly.
Thanks a lot for pointing to the original documentation, Michelangelo.
If one needs a specific Config for the hardware, how is it supposed to be implemented (I only see the ability to manipulate the audio flux, not the hardware settings)?
Yes, but this is only partly the information we are looking for I think. Since some of the asound.conf (Default, Volumio, VolumioHw, VolumioOutput) Is hardcoded in the index.js of the alsa_controller plugin. Which basically makes it not possible to easily change the asound.conf for testing purposes on hardware related level. I think this indeed works properly for software implementation and testing, but for hardware it makes it quite difficult. I for example want to bypass all outputs except VolumioHw.
I either have to:
Change asound.conf and then systemctl restart mpd.
Or
Change the output device of mpd.conf and then systemctl restart mpd. You can however change the mpd.conf.tmp to set the output device in the mpd plugin in music_service. You can then restart Volumio with the output device wanted.
.