local audio: allow to select bitrate/depth from gui#3738
Conversation
|
PS, no clue how I can set the label |
|
First of all great to see you getting involved with the codebase, thanks! |
| if self.player_id.startswith(BRIDGE_PREFIX): | ||
| entries.append(create_sample_rates_config_entry(max_sample_rate=192000, max_bit_depth=24)) |
There was a problem hiding this comment.
This config entry should not be needed because Sendspin has a different way of handling this.
The sample rate config entry basically only exists for HTTP based players
There was a problem hiding this comment.
After spending a bit more time on 3724, I believe I now understand this comment.... but kindly confirm.
In case of local_audio using sendpin, the sample_rates has to come from the device at the moment of registration. If this is true then it is quite a challenge to not oversample all the time. Example: my HDMI can go from 48k to 192k and I would then 'hard'-config my device at 192k so I can benefit if/where needed (ignoring the audibility topic :) ). My idea(l) approach would then be to retrieve the capabilities of the hdmi device (e.g. allowed_rates in pipewire.conf) and then match that with the source (file) rate, get the closest match, and stream with that 'matched' rate.
If this is the direction it should be heading then I will close this PR ... any further chat we could do on discord if/where needed :)
EDIT: just realised that I have only been looking at pulse and alsa on my ubuntu 24.04 so far but if the OS is mac or windows or ?? android ?? ...what then? Does that require windows/macos-specific integration then alike 3724?
EDIT2: it is not easy to get the (OS configured) supported rates from the devices, and this again goes in favor of allowing the local_audio devices to be configured in MA.... but I do (!) admit (!) that I am still learning so maybe I miss things :)
There was a problem hiding this comment.
Adding, I played around a bit as to come to a solution mathcinh device-supported rates vs. source (file) rate.
My laptop has :
- analog audio, currently limited to 48k (pw setting)
- hdmi , 48k > 192k
- usb to dac, up to 768k
Step 1, and this also related to this PR, detect capabilites
A bit (well) of code changes in the 3724 pulse stuff (which is fixed at 48k), and it can detect all these devices and use them when streaming. ...not without issues though and I am questioning (you) where to add limits....i.e. add limits even if the hardware can go beyond. Should MA have a max-rate or should it be limited by the settings in pw/alsa or should it be a configuratle option in sendpsin (although you stated this is not the right type of device (no http)
|
Marking as draft so we can first see if #3724 already handles this |
It seems to work here with PR #3724 on HDMI as expected and sounds fine. The modifications to /etc/pulse/daemon.conf may need to be reapplied when rebooting or the hassio_audio container is restarted in order to have the higher sample rate and bit depth. I don't if/when persistent daemon.conf settings will be possible.
|
"This' as bing able to properly stream to HDMI in general,or ? EDIT: I will await your feedback whether or not I should continue with above suggestion and further testing |
|
@marcelveldt And with that I see the pulse/pipe devices of my laptop, I can (with this PR) modify the rate/depth and play nicely too |
Hi, I may have misread your comment, did you add (part of) my PR to yours and tested that? I ran your PR (container-installed pulseaudio-utils) and this seems fixed to 48k/32b. |
I did not add anything from your PR to PR #3724. PR #3724 alters the local_audio provider so that it finds all pulse audio sinks and creates sendspin players for them. The current local_audio provider only creates a sink only for the default pulse audio sink chosen in the MA addon/app configuration. The idea is that sendspin sinks are created automatically on the pulse audio level which is built into MA and does not require any additional user configuration. I would rather not be configuring things at the alsa level if possible. This approach should continue to work even if HA audio eventually moves to pipewire. Altering /etc/pulse/daemon.conf in the hassio-audio container is all that is needed get at least a 96000 sample rate and 32 bit format where supported by the DAC. I have used a wide variety of DACs and they all are able to obtain their best sample rate and bit depth with the daemon.conf configuration. Eventually there will be a way to keep these conguration changes persistent across container restarts. hassio-audio:/# pactl list sinks short Does this answer your question or provide the solution you were looking for? |
OK, thanks so from what I read it is a fixed rate ... and that is exactly what my PR tries to change, I have local audio from 32k mp3 to beyond 192k and I would like to play these at-a minimum at their original rate, limited only by the HDMI device rate. To be able to select the device capabilitities is a must imo, there will be devices that can only handle 44.1 and others that can go way beyond and the user should be able to decide. Note that I do not want to enter in discussions whether or not this is audible, that is a whole different rabbit hole and not my point :). So, I may need re-do my PR after yours goes live (unless you add gui-level rate-selection too ??), and only when I know/understand what MASS is aiming to support :) |
Do note my last comment, there should not be a discussion on what you or me or anyone else thinks is 'good enough'. Any solution limiting the user's choice based on opinions, especially when there are more options, is not good ... by default. If the device can play hihger rates and if the user wants/believes/dreams/etc. to need that, then why not? The only limitations I understand is when MASS has architectural limits, e.g. streaming to MPD is limited to mp3 due to the continuous stream setup. I will try to see tomorrow how I can make by system pick a best rate. Final comment, the ideal setup is not the best rate of the device but the next-best-rate based on the source. E.g. if 32k mp3 is played then no need to upsample to 192k if that is the best rate the device can handle... this is a different challenge though. .... and with that, my PR has more issues to tackle :) |
|
cancelling as deviates too much from the required non-manually-configured setup |


background/context:
I would like to stream locallly via HDMI, which is connected to my (Denon) receiver, from my ubuntu laptop 24.04
There is a mismatch between what MASS sends out and what HDMI handles, i.e. 44.1k vs. 48k. There are manual workarounds but they require docker volumes/updates and a lot of knowledge, not for the ordinary user.
This PR proposes to be able to select the bitrate and bitdepth via the GUI, in line with other providers.
Notes:
Disclaimer: I lack an overall architectural view of MASS so this may be out of tune :)