[Feature] Add support for a prefix for asound.conf

[GioF71]

Add ASOUND_FILE_PREFIX variable. If set, this will be used as prefix.
e.g. say that

ASOUND_FILE_PREFIX=topping-d10

instead of looking for asound.conf in userconfig, we will look for

topping-d10.asound.conf

[hv6478]

Are we able to apply these settings by adding flags when creating the .env file? I see there are many lower-case references to things to update easily, but there is another list with more things that are all in CAPS. I think it may be possible to route audio through the MPD or alsa (for moOde and Volumio) so that we can use EQs or CamillaDSP with Tidal Connect. Otherwise it seems to bypass and go straight to the USB DAC. This may also help address the related open issue #74

[GioF71]

Hello, I do not understand what you mean by saying

I see there are many lower-case references to things to update easily, but there is another list with more things that are all in CAPS

Are you referring to the entrypoint.sh script?

About routing to mpd, I responsed on that issue.

[hv6478]

Hello, I do not understand what you mean by saying

I see there are many lower-case references to things to update easily, but there is another list with more things that are all in CAPS

Are you referring to the entrypoint.sh script?

About routing to mpd, I responsed on that issue.

Yes, this step:

./configure.sh -n "X20" -f "Desktop" -m "Raspberry Pi"

I can see you (very helpfully and conveniently) set many parameters that can control the variables of the entrypoint for the container. However, for something ASOUND_FILE_PREFIX I am not seeing a reference in the list of parameters to change that. I was wondering how I would indicate this, perhaps a manual write to the .env file before (re)creating with docker-compose?

Thanks again, wonderful work you are doing!

[GioF71]

Hello, I do not understand what you mean by saying

I see there are many lower-case references to things to update easily, but there is another list with more things that are all in CAPS

Are you referring to the entrypoint.sh script?
About routing to mpd, I responsed on that issue.

Yes, this step:

./configure.sh -n "X20" -f "Desktop" -m "Raspberry Pi"

I can see you (very helpfully and conveniently) set many parameters that can control the variables of the entrypoint for the container. However, for something ASOUND_FILE_PREFIX I am not seeing a reference in the list of parameters to change that. I was wondering how I would indicate this, perhaps a manual write to the .env file before (re)creating with docker-compose?

Yes, of course that convenience script has not grown to cover all the functionalities that can be set with variables. To tell you the truth, I do not know how users use this compose file: do most people tweak the .env file directly, or do most people just run the script, so they expect it to cover all the features?
Does the configure.sh script make sense at all?
That said, I can definitely add support for that ASOUND_FILE_PREFIX in the configure.sh. I will do that asap.

Thanks again, wonderful work you are doing!

Thank you for the kind words.
From time to time I think about tearing down this repo, because I really don't like how the binaries (which I do not include here) have been sourced. In fact, I mention all the possible alternatives I know of in the README.md.

[hv6478]

I notice that as well. I do enjoy tinkering and figuring things out, as I'm sure all of us do! I have a WiiM Mini out in the living room where the AVR is room-corrected and EQ is not a concern. The EQ implementation in the WiiM devices leave a LOT to be desired though. The Volumio paid integration has had many mixed reviews and with an ongoing monthly fee I do not think it's ready. I'm sure 5 years from now it will look quite different.

Regarding the script, I'm not sure otherwise but, personally, I like the configure.sh option as it's neat and tidy. I've seen you reference the option to echo different lines into it as well, so that is always good to know!

I think also the FORCE_PLAYBACK_DEVICE and CREATED_ASOUND_CARD_NAME (maybe second one not as much) could be helpful to quickly be able to configure as well. But now we are getting close to just having all of the parameters as configure.sh options LOL.