07:24 <jbrunet> hexdump0815: you don't pick your pll. Because there is usually more consumers than plls, each one is set to match a rate family (48k, 44.1k, 64k) multiplied by 32 x 24 for the different bit width. The result is then multiplied by 2 until the pll maximum supported rate is reached.

07:26 <jbrunet> When the audio driver requests a rate (say 48k), the clock framework will automatically reparent the audio clock with pll giving the best matching result

07:28 <jbrunet> Looking at your plls, it seems fine. mpll0 is set for 48k (and derivatives), mpll1: 44.1k, mpll2: 64k

07:31 <jbrunet> and cts_amclk is possibly set for 44.1k x 8ch x 32bits

07:33 <jbrunet> so if the wav you are playing is encoded with 48k and you are playing at 44.1k, then yes - the playback will be slow.

20:06 <hexdump0815> jbrunet: thanks for your response - i think i understand part of it - so clocks are assigned automatically and we seem to have proper clocks for 32,44.1 and 48khz around

20:07 <hexdump0815> what i do not understand is why does for instance a video in firefox on the working box is playing at the proper speed and one on the non working box at a too slow speed? both have about the same setup

20:08 <hexdump0815> is the audio hw setup on such boxes able to "physically" play 32, 44.1 and 48khz? it seems like it is the case to me

20:10 <hexdump0815> my experience so far was that firefox/pulseaudio/alsa usually negotiates the proper sample rate between what is being played and what the hardware is capable of and worst case will resample accordingly

20:11 <hexdump0815> so far i never had any issues with wrong speed sound on any analog output with linux yet - except in this case

20:42 <hexdump0815> ok - i did some tests with jackd/qjackctl which allows me to set all the audio params like sameple rate etc. and i can set the audio device properly to 32/44.1/48 and the current setting is reflected well in /proc/asound/card0/pcm0p/sub0/hw_params

20:43 <hexdump0815> in parallel i can see that in the clk_summary everything is rearranged accordingly so that the audio clock is derived from the best mpllx

20:45 <hexdump0815> and i can run firefox via pulseaudio over jack and still speed is too slow/pitch too low ... i guess this hardware is really broken and some part of the audio hw is running internally with some wrong clocks resulting in this mismatch

20:45 <hexdump0815> in the end its a tv box and broken or wrongly wired hardware is not unlikely :)