Randomly slow speed in HI_RES_LOSSLESS flac

[fmarzocca]

I am running mopidy on a Raspberry 3B+, download speed is 70 Mbps.

Randomly, when playing an HI_RES_LOSSLESS (Flac) track, the playing speed slows down to very low rates. To give you an idea, I am attaching here an audio file of the issue. If I switch to the next track, the playback is back to normal. How can I force to MQA?

HiResLosslessFlac.m4a.zip

[fmarzocca]

This are my settings in /etc/mopidy/mopidy.conf (which is a link to $HOME/.config/mopidy/mopidy.conf):

[tidal]
enabled = true
quality = HI_RES
auth_method = PKCE
login_server_port = 8989
lazy = false

But if I type mopidy config in the console, this is what I get:

[tidal]
enabled = true
quality = LOSSLESS
client_id = 
client_secret = 
playlist_cache_refresh_secs = 0
lazy = false
login_method = AUTO
auth_method = OAUTH
login_server_port = 8989

[tehkillerbee]

As per mopidy instructions https://docs.mopidy.com/latest/config/:

To see what’s the effective configuration for your Mopidy installation, you can run the config subcommand. If you run Mopidy manually in a terminal, run: mopidy config If you run Mopidy as a system service, run: sudo mopidyctl config

For me, i used the latter and the config reflects the config set in /etc/mopidy/mopidy.conf so perhaps that is why the config does not match?

How can I force to MQA?

Setting HI_RES quality will usually switch to MQA only(?) playback but not sure if it would fix your issue. But be aware that you need to use OAUTH authentication as well. This is not clear from the README, sorry! You could also reduce the quality to LOSSLESS to have a non hi-res lossless FLAC.

I have never seen the issue you describe before. Please include some log info so we can see what is going on on the mopidy side, specifically the codec/audio resolution stuff. Are you using the RPI HDMI as the audio source?

[fmarzocca]

My bad, sorry. Running sudo mopidyctl config the 2 configs are the same.

Setting HI_RES quality will usually switch to MQA only(?)

Nope. I tried and it still reports HI_RES_LOSSLESS (flac) on tracks.

Please include some log info so we can see what is going on on the mopidy side

Absolutely nothing weird in mopidy's log. When the issue occurs, no log line is appended. I am using PKCE authentication

[tehkillerbee]

On my side, setting HI_RES + OAUTH usually results in MQA playback. If not, perhaps try to re-authenticate to make sure that your session is in fact an OAUTH session. You can also look directly in the json file and make sure it does not say is_pkce=True. If it does, you should delete it and reauthenticate.

I doubt this issue is caused by anything in mopidy-tidal or tidalapi's end, as the MPD manifest is just passed on to GStreamer. What version of GStreamer are you using?

[fmarzocca]

What version of GStreamer are you using?

1.22.0 I didn't try OAUTH authentication with HI_RES. Do I have to re-authenticate and lose my PKCE auth? The Readme states:

OAUTH used as default and allows playback up to LOSSLESS (HiFi)
PKCE is required for HI_RES, HI_RES_LOSSLESS (HiFi+) playback.

[tehkillerbee]

PKCE is required for HI_RES, HI_RES_LOSSLESS (HiFi+) playback.

I believe only HI_RES_LOSSLESS requires PKCE so I should update the documentation. You should be able to switch freely between oauth and pkce. If the respective session file is missing, you will be requested to reauthenticate.

[fmarzocca]

Are you using the RPI HDMI as the audio source?

Yes.

[fmarzocca]

@tehkillerbee at this point I am really confused... I have set OAUTH and HI_RES in mopidy-tidal configuration, but I am still playing tracks HI_RES_LOSSLESSand FLAC, which are going to raise the issue of the playing speed. Isn't there any way to stick with MQA? 2024-03-22 10:32:51,076 INFO [2052:TidalBackend-3 (_actor_loop)] mopidy_tidal.playback: Starting playback of track:275613329, (quality:HI_RES_LOSSLESS, codec:flac, 24bit/44100Hz)

This is from mopidy log:

2024-03-22 10:29:13,369 INFO [2052:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: Quality: HI_RES
2024-03-22 10:29:13,370 INFO [2052:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: Authentication: OAuth

[tehkillerbee]

Please include the full log after startup + playback of the track has begun. Also if you can include the album, I can test on my end since MQA worked fine when I tested it yesterday with HI_RES.

Also, try to delete your OAUTH session file to make sure that it is recreated.

[fmarzocca]

2024-03-22 10:53:57,297 INFO [2372:TidalBackend-3 (_actor_loop)] mopidy_tidal.playback: TIDAL uri: tidal:track:3557299:323856439:323856442
2024-03-22 10:53:57,670 INFO [2372:TidalBackend-3 (_actor_loop)] mopidy_tidal.playback: MimeType:application/dash+xml
2024-03-22 10:53:57,671 INFO [2372:TidalBackend-3 (_actor_loop)] mopidy_tidal.playback: Starting playback of track:323856442, (quality:HI_RES_LOSSLESS, codec:flac, 24bit/48000Hz)
2024-03-22 10:53:58,313 INFO [2372:TidalBackend-3 (_actor_loop)] mopidy_tidal.library: Searching Tidal for images for ['tidal:track:3557299:323856439:323856442']

[tehkillerbee]

You should include the whole log since restarting mopidy so we can see what session that is loaded.

Did you delete the OAUTH session and reauthenticate?

[fmarzocca]

Yes, I deleted the OAUTH json file, but this is mopidy's log at startup. It is not asking me to visit the url:

2024-03-22 11:05:28,912 INFO [2575:MainThread] mopidy.__main__: Starting Mopidy 3.4.2
2024-03-22 11:05:29,059 INFO [2575:MainThread] mopidy.config: Loading config from builtin defaults
2024-03-22 11:05:29,072 INFO [2575:MainThread] mopidy.config: Loading config from file:///usr/share/mopidy/conf.d/mopidy.conf
2024-03-22 11:05:29,073 INFO [2575:MainThread] mopidy.config: Loading config from file:///usr/share/mopidy/conf.d/mopidy-local.conf
2024-03-22 11:05:29,074 INFO [2575:MainThread] mopidy.config: Loading config from file:///home/pab/.config/mopidy/mopidy.conf
2024-03-22 11:05:29,081 INFO [2575:MainThread] mopidy.config: Loading config from command line options
2024-03-22 11:05:30,111 INFO [2575:MainThread] mopidy.__main__: Enabled extensions: local, softwaremixer, tidal, alsamixer, podcast, internetarchive, mpd, file, iris, stream, mopiqtt, podcast-itunes, soundcloud, tunein, m3u, http
2024-03-22 11:05:30,112 INFO [2575:MainThread] mopidy.__main__: Disabled extensions: spotify, scrobbler
2024-03-22 11:05:31,581 INFO [2575:MainThread] mopidy.commands: Starting Mopidy mixer: SoftwareMixer
2024-03-22 11:05:31,585 INFO [2575:MainThread] mopidy.commands: Mixer volume set to 90
2024-03-22 11:05:31,586 INFO [2575:MainThread] mopidy.commands: Starting Mopidy audio
2024-03-22 11:05:31,593 INFO [2575:MainThread] mopidy.commands: Starting Mopidy backends: TidalBackend, FileBackend, M3UBackend, StreamBackend, InternetArchiveBackend, LocalBackend, PodcastBackend, iTunesPodcastBackend, SoundCloudBackend, TuneInBackend
2024-03-22 11:05:31,606 INFO [2575:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: Mopidy-Tidal version: v0.3.6
2024-03-22 11:05:31,622 INFO [2575:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: Python-Tidal version: v0.7.5
2024-03-22 11:05:31,628 INFO [2575:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: PKCE login web server port: 8989
2024-03-22 11:05:31,635 INFO [2575:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: Quality: HI_RES
2024-03-22 11:05:31,637 INFO [2575:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: Authentication: OAuth
2024-03-22 11:05:31,638 INFO [2575:Audio-2 (_actor_loop)] mopidy.audio.actor: Audio output set to "autoaudiosink"
2024-03-22 11:05:31,644 WARNING [2575:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: AUTO login implies lazy connection, setting lazy=True.
2024-03-22 11:05:31,656 INFO [2575:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: Login method: AUTO
2024-03-22 11:05:31,657 INFO [2575:TidalBackend-3 (_actor_loop)] mopidy_tidal.backend: Using default client id & client secret from python-tidal
2024-03-22 11:05:32,328 INFO [2575:SoundCloudBackend-11 (_actor_loop)] mopidy_soundcloud.actor: Logged in to SoundCloud as 'saltydog'
2024-03-22 11:05:32,330 INFO [2575:MainThread] mopidy.commands: Starting Mopidy core
2024-03-22 11:05:32,394 INFO [2575:MainThread] mopidy.commands: Starting Mopidy frontends: IrisFrontend, MopiqttFrontend, HttpFrontend, MpdFrontend
2024-03-22 11:05:32,397 INFO [2575:IrisFrontend-14 (_actor_loop)] mopidy_iris.core: Starting Iris 3.69.3
2024-03-22 11:05:32,407 INFO [2575:HttpFrontend-17 (_actor_loop)] mopidy.http.actor: HTTP server running at [::ffff:0.0.0.0]:6680
2024-03-22 11:05:32,414 INFO [2575:MainThread] mopidy_mpd.actor: MPD server running at [::]:6600
2024-03-22 11:05:32,421 INFO [2575:MainThread] mopidy.commands: Starting GLib mainloop
2024-03-22 11:05:32,463 INFO [2575:paho-mqtt-client-mopidy-2001] mopiqtt.mqtt: Successfully connected to MQTT broker, result :Success

[fmarzocca]

I ill try again. The login auth method is always a PITA...

[fmarzocca]

Ok. Clearing OAUTH json and restart, login again, it worked!

Now the FLAC tracks are playing with MQA. I hope I do not have to delete the PKCE json file, as that login was really a nightmare! :-)

Thank you.

[tehkillerbee]

Good to hear. I believe there is a bug causing the OAUTH session to be stored as PKCE (i.e. hi_res=true) in certain situations. Not entirely sure why this happens but I will look into it when I have time.

No, the idea is that you should be able to switch between the two auth methods, without having to reauthenticate if the file exists.

The real cause of the slowness is still a mystery. I also use a RPi3B+ with an USB DAC attached and it works without any issues at all with all qualities up to HI_RES_LOSSLESS.

[fmarzocca]

The real cause of the slowness is still a mystery. I also use a RPi3B+ with an USB DAC attached and it works without any issues at all with all qualities up to HI_RES_LOSSLESS.

Could it be a network issue? But I have no evidence in any log...

[fmarzocca]

@tehkillerbee this is current network throughput:

Idle Latency:    10.15 ms   (jitter: 10.78ms, low: 9.67ms, high: 30.68ms)
    Download:    73.03 Mbps (data used: 83.4 MB)                                                   
                 57.54 ms   (jitter: 8.12ms, low: 17.56ms, high: 117.36ms)
      Upload:    16.58 Mbps (data used: 13.9 MB)                                                   
                 34.73 ms   (jitter: 3.90ms, low: 11.67ms, high: 50.37ms)
 Packet Loss:     0.0%

A side note: I am getting the audio from RPI HDMI out, then into an HDMI-analog audio converter. Could it be that one the cause? Which USB DAC are you using?

[tehkillerbee]

@fmarzocca

Hmm network speeds look more than adequate.

Have you noticed if the issue occurs with specific audio resolutions? You should be able to see this in the log.

Could it be that one the cause?

Yes, perhaps the converter is not able to keep up?

I currently use two different USB DACs with no issue.

• SMSL M300SE
• Cambridge audio dacmagic plus.

I just got the SMSL - very good bang for the buck, around 130EUR. The dacmagic is pretty old now and I'm planning to upgrade it soon.

[fmarzocca]

Yes, I believe my HDMI converter is the culprit. It is a very cheap one and have to decide if to use an USB DAC or an HDMI one.

Have you noticed if the issue occurs with specific audio resolutions?

Yes, it was occurring only with HI_RES_LOSSLESS / FLAC. Now I moved to MQA I never had the issue anymore.

You should be able to see this in the log.

I can see quality/codec in my system. I decided not to put the audio resolution as it will mess up the interface: