Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Intermittent loud ticks and no-audio using Spotify
#41
(10-12-2020, 10:39 AM)JasonLG1979 Wrote:
(10-12-2020, 10:33 AM)the_bertrum Wrote: "just" the four most dangerous letters in programming.

It can't be any worse then several different apps with varying quality ALSA backends.

And "just" is always followed up with and example of where someone else has already done it as if that proves it is easy.  It some kind of universal law I think.
----------------
Robert
Reply
#42
(10-12-2020, 11:35 AM)the_bertrum Wrote:
(10-12-2020, 10:39 AM)JasonLG1979 Wrote:
(10-12-2020, 10:33 AM)the_bertrum Wrote: "just" the four most dangerous letters in programming.

It can't be any worse then several different apps with varying quality ALSA backends.

And "just" is always followed up with and example of where someone else has already done it as if that proves it is easy.  It some kind of universal law I think.

Well people have written several ALSA plugins so there's that...
Reply
#43
You could look at plug (horrible name, it's a resampling plugin) to see how it locates and uses libsamplrate and speex as a guide to implementing sox resampling.

Upping bit depth is just a matter of zero padding.

You could look at dmix and/or dshare to see how they override the buffer parmas.
Reply
#44
It's not a matter of it being easy. It's a matter of consistency, reproducibility and the ability to have a global system wide configuration compared to having to configure each app separately. I get that MPD is the main focus and playback method but I would think you'd want all apps to behave and be configured in the same way. They all have to go through ALSA that's the thing they all have in common in the end. ALSA is the logical configuration point.
Reply
#45
(10-12-2020, 11:54 AM)JasonLG1979 Wrote: You could look at plug (horrible name, it's a resampling plugin) to see how it locates and uses libsamplrate and speex as a guide to implementing sox resampling.

Upping bit depth is just a matter of zero padding.

You could look at dmix and/or dshare to see how they override the buffer parmas.

Of course, I've been a fool.  Simples.

Off you go then...
----------------
Robert
Reply
#46
(10-12-2020, 01:00 PM)the_bertrum Wrote:
(10-12-2020, 11:54 AM)JasonLG1979 Wrote: You could look at plug (horrible name, it's a resampling plugin) to see how it locates and uses libsamplrate and speex as a guide to implementing sox resampling.

Upping bit depth is just a matter of zero padding.

You could look at dmix and/or dshare to see how they override the buffer parmas.

Of course, I've been a fool.  Simples.

Off you go then...

Not my job. I don't use MoodeAudio and I have no need for such a plugin. I tried Moodeaudio for a while but when I raised the issue of poor web interface design, namely the UI not being designed in a way to be aspect ratio agnostic I was told to buy an ipad.
Reply
#47
@basmeyer

I don't want to extend this thread any more than I have to but since it has been suggested that somehow our July build of librespot may be to blame, I cloned the current librespot github repo and built a new armv6l binary from the dev branch.

I zipped the binary using the zip routine distributed in moOde 6.7.1 and uploaded it to dropbox.com.

https://www.dropbox.com/s/ypje9pgoqyyxu3...t.zip?dl=0

If you so choose, download it to your moOde 6.7.1 player, unzip it, as root copy the binary to /usr/local/bin/librespot, make sure it is marked executable, and reboot.

This new binary is working for me but so is the distributed July build of it. I cannot repro your reported problem so there is nothing more I can do.

A doubting Thomas might say, "sure, but this is an armv6l binary and maybe that's the cause of my problems." The reason we build only an armv6l binary of librespot is stated in the build instructions. Anyone can always build the armv7l binary instead but I'm done here.

Good luck,

Regards,
Kent
Reply
#48
(10-13-2020, 05:00 PM)TheOldPresbyope Wrote: If you so choose, download it to your moOde 6.7.1 player, unzip it, as root copy the binary to /usr/local/bin/librespot, make sure it is marked executable, and reboot.

Thanks Kent!
Had it all done and new librespot in place, plays allright, although it was mandatory to let the librespot.zip file be upzipped on the Pi. I had it upzip first by Dropbox I think and then move it to the Pi but that would not give a recognisable/playable Spotify Connect instance. But that is exactly wat you said, and the doing it a bit different gave me a tiny headache instead.

But.... still nasty spikes! Unfortunately.
With this output of

pi@moOde:~ $ cat /proc/asound/card2/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (352800/8)
period_size: 5513
buffer_size: 22052


So, with period and buffer sizes OK now, from what I learned from Jason.

I have the idea that the spikes appear a tiny bit less often but still they are easy to reproduce. Play Spotify with a HiFiBerry DAC+ Pro card on a RP4, skip to next track after a few seconds a few times and PAC!!!!!
Perhaps it has to do with the XLR version... which further limits the number of people that might have the same problem.
But I cannot have moOde slowly kill my gear, I have nice active KRK monitors on it in the living room. So that will be the end of it for now until any improvement or further testing.

I like moOde, it has great potential. It is not perfect yet and I would love to see way more essential user features (compare to the extended technical/audiophile features that seems to receive relatively way more attention). But the alternatives, HiFiBerryOS and Volumio are, well... FAR from perfect? I mean they miss a LOT and especially in UI, not going into details.
HiFiBerryOS dóes play Spotify Connect without problems though and that is what we relatively use the most here.

So for now I have to go with that here at home that and see what happens with moOde..... or, later invest the $$ and forget about the current DAC and casing and go for something else. I do like the balanced output version of this DAC, well...
Thanks in advance for any improvements and all the work that relates to this!
Reply
#49
In a stock moOde config hw_params for Spotify renderer would show rate: 44100 (44100/1)

Do you know why your hw_params shows 44100 (352800/8) ?

It looks like the PCM stream being output from the Spotify renderer is being upsampled after the fact by ALSA.

It's very odd.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#50
(10-14-2020, 02:51 AM)Tim Curtis Wrote: In a stock moOde config hw_params for Spotify renderer would show rate: 44100 (44100/1)

Do you know why your hw_params shows 44100 (352800/8) ?

It looks like the PCM stream being output from the Spotify renderer is being upsampled after the fact by ALSA.

It's very odd.

Anything to do with the HiFiBerry DAC+ Pro master mode interaction with Spotify renderer ?

Bob...(janitor Wink )
----------
bob
Reply


Forum Jump: