Open Trilis29 opened 5 months ago
I don't see why not. Can you post the output of
cat /proc/asound/cards
so I might help you create a configuration file. Also can you please give me some information about your setup? Operating system, Pi/SBC model, etc...
Looking here it seems that the name of the device is "Qutest", so you might be able to make it work by running:
./configure.sh -n "Qutest"
then start the container using
docker-compose up -d --force-recreate
Watch the logs using
docker-compose logs -f
Hello, did this work? If so, I might update the documentation and include a sample config file for this DAC. Thank you
I will update you next week, I am on holiday can not check now :)
Hello, have you tried this? If so, I can add sample configurations for others to use. Thank you
Yes working with Qutest.
But it is strange that I can not get FLAC quality, my bitrate is only 44.1kHz
Every 2.0s: cat /proc/asound/card0/pcm0p/sub0/hw_params mopidy: Mon Aug 5 00:18:35 2024
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2205
buffer_size: 11025`
Isn't that because tidal just removed all mqa content? This happened just a few days ago. I cannot try right myself now, maybe next week... This implementation of tidal connect supports up to 24/48, rates up to 88/96 happen (or used to happen) because of mqa unfolding. I am afraid that with the latest move from tidal we might be limited to 24/48 or even to standard quality. If hires is important for you, you might want to consider the alternatives listed on the readme. BubbleUPnP playback to mpd/upmpdcli is cheap and convenient. Or you might want to use the tidal plugin for upmpdcli and use any dlna/upnp controller like mconnect. Let me know if this helps or it you need further information.
Yes working with Qutest.
So is "Qutest" the name of the alsa device?
Yes working with Qutest.
So is "Qutest" the name of the alsa device?
correct
Isn't that because tidal just removed all mqa content? This happened just a few days ago. I cannot try right myself now, maybe next week... This implementation of tidal connect supports up to 24/48, rates up to 88/96 happen (or used to happen) because of mqa unfolding. I am afraid that with the latest move from tidal we might be limited to 24/48 or even to standard quality. If hires is important for you, you might want to consider the alternatives listed on the readme. BubbleUPnP playback to mpd/upmpdcli is cheap and convenient. Or you might want to use the tidal plugin for upmpdcli and use any dlna/upnp controller like mconnect. Let me know if this helps or it you need further information.
It seems that upnp will be only choice, Also tried mopidy-tidal still low bitrate. uPnP problem is that when track finished playing next similar song does not start (what is preffered). So will check all alternative solution, maybe you have idea?
Isn't that because tidal just removed all mqa content? This happened just a few days ago. I cannot try right myself now, maybe next week... This implementation of tidal connect supports up to 24/48, rates up to 88/96 happen (or used to happen) because of mqa unfolding. I am afraid that with the latest move from tidal we might be limited to 24/48 or even to standard quality. If hires is important for you, you might want to consider the alternatives listed on the readme. BubbleUPnP playback to mpd/upmpdcli is cheap and convenient. Or you might want to use the tidal plugin for upmpdcli and use any dlna/upnp controller like mconnect. Let me know if this helps or it you need further information.
It seems that upnp will be only choice, Also tried mopidy-tidal still low bitrate. uPnP problem is that when track finished playing next similar song does not start (what is preffered). So will check all alternative solution, maybe you have idea?
Hello, the issue with next track not playing using UPnP depends usually on the fact that the media server is the Phone/Tablet. If you are using BubbleUPnP, this can be solved by running BubbleUPnP server (a java application, runnable with docker as well): you need to let BubbleUPnP server "manage" your renderer (to be created if using upmpdcli with RENDERER_MODE=UPNPAV or RENDERER_MODE=BOTH) by creating an OpenHome Renderer inside BubbleUPnP server. The java application will work with the renderer and the mobile app, will retain the playlist so you won't have the issue you have experimented.
Another option, if you want to use the tidal plugin for upmpdcli, is to simply create the renderer using either RENDERER_MODE=OPENHOME or RENDERER_MODE=BOTH. This way, when you use BubbleUPnP to browse the library offered by the upmpdcli media server, and you add tracks to the player, the phone going to sleep (or anything) will not determine the playback to stop. The playlist in this will be retained by the renderer, the phone is not the media server, so we avoid those issues.
About mopidy, it does work with hires at least a few days ago. It uses the same library as the tidal plugin for upmpdcli. The author of the plugin is now the main contributor to that plugin. Have you tried to follow the login instructions here? It's a bit convoluted but it's generally a one-time only operation.
Other options, well you might try either Roon and Audirvana, they have a trial period. I tried both, no issues. Lyrion Music Server (was Logitech) also works, maybe limited to standard or up to 24/48, but it works.
Just added the sample config file for the Qutest DAC :-)
Will this dac going to be supported?