(12-17-2019, 12:10 AM)Tim Curtis Wrote: Audio glitches are not normal. I don't experience them on any of my 6 systems but I'm using only I2S DAC's, MPD, and the renderers: Bluetooth, Airplay, Spotify, Squeezelite/LMS.
The challenge in troubleshooting an issue like the one your are describing is that the moOde crew would need to be able to reproduce it. We don't have Roon, Hugo or other pieces in your system.
Generally though you would want to first isolate the issue. This is accomplished by first creating the simplest configuration that plays your files perfectly, then make changes to the configuration, one at a time and re-test until your reach a configuration where the issue occurs.
-Tim
I "think" I have found it. Roon sends FLAC files with compression. In the advanced settings of the endpoint I turned that off and it seems to have fixed the problem.
Bob
In my limited experience I found that decoding FLAC on a Raspberry Pi is not optimal. I recently decoded all my FLAC files to AIFF. FLAC was created when storage space and bandwidth was limited, this is no longer the case. I think AIFF playback is smoother on a Pi. (this could also be in my head...)
With the exception of test files and files submitted by users for forensic examination, all of my collection is FLAC encoded.
FLAC is the "free lossless audio codec". Lossless refers to its compression algorithm. When encoding, one can select a compression level from 0 to 8.
Level 0 is the least amount of compression and requires the least amount of encoding time. Level 8 is the greatest amount of compression and requires a much greater amount of encoding time.
The default tends to be compression level 5, apparently chosen as a compromise between amount of compression and compression time required to achieve it.
Decoding times are relatively independent of the level of compression.
Perhaps it's the level of compression being used which is causing a problem, if FLAC encoding is being done on the fly at the server end.
FYI, I have had no glitches in playback of my pre-encoded FLAC material (mostly compressed to the default level 5) on any of my moOde players.
These days I use mainly an RPi3A+ with USB-BT adapter (apX encoder) for my headphones and an RPi4B with USB Khadas Tone Board connected to my main system, but I also have an RPi3B+ with I2S HiFiBerry DAC+ I use occasionally. As well, there's an RPi0W lying around which gets exercised with output to Bluetooth or to a cheap USB-audio adapter during tests. All use WiFi to connect to my LAN and thence to my NAS boxes and to the Internet
(12-17-2019, 12:10 AM)Tim Curtis Wrote: Audio glitches are not normal. I don't experience them on any of my 6 systems but I'm using only I2S DAC's, MPD, and the renderers: Bluetooth, Airplay, Spotify, Squeezelite/LMS.
The challenge in troubleshooting an issue like the one your are describing is that the moOde crew would need to be able to reproduce it. We don't have Roon, Hugo or other pieces in your system.
Generally though you would want to first isolate the issue. This is accomplished by first creating the simplest configuration that plays your files perfectly, then make changes to the configuration, one at a time and re-test until your reach a configuration where the issue occurs.
-Tim
I "think" I have found it. Roon sends FLAC files with compression. In the advanced settings of the endpoint I turned that off and it seems to have fixed the problem.
Bob
Hi Bob,
FLAC format is by spec compressed and the codec is universally implemented in FOSS. I don't have any experience with Roon software but can you post a screen shot of the settings page for the endpoint?
(12-17-2019, 12:10 AM)Tim Curtis Wrote: Audio glitches are not normal. I don't experience them on any of my 6 systems but I'm using only I2S DAC's, MPD, and the renderers: Bluetooth, Airplay, Spotify, Squeezelite/LMS.
The challenge in troubleshooting an issue like the one your are describing is that the moOde crew would need to be able to reproduce it. We don't have Roon, Hugo or other pieces in your system.
Generally though you would want to first isolate the issue. This is accomplished by first creating the simplest configuration that plays your files perfectly, then make changes to the configuration, one at a time and re-test until your reach a configuration where the issue occurs.
-Tim
I "think" I have found it. Roon sends FLAC files with compression. In the advanced settings of the endpoint I turned that off and it seems to have fixed the problem.
Bob
Hi Bob,
FLAC format is by spec compressed and the codec is universally implemented in FOSS. I don't have any experience with Roon software but can you post a screen shot of the settings page for the endpoint?
I dunno. Maybe they are sending everything as raw PCM to their endpoint or something like that and so for this particular format they offer to send it in its native format ?? There is no help text or hints on their config page that explains what this option does.
moOde/MPD decodes and plays FLAC in its native format directly to the attached audio device. There is no remote server, endpoint or network in-between that could cause issues.
Reading between the lines, it means Roon is transcoding everything which isn't FLAC into FLAC when this setting is enabled. This dovetails with my previous conjecture that FLAC encoding on-the-fly on your server could be leading to problems.
I note that Roon makes explicit statements about the need for adequate computing power.
Slow servers, NAS's, and network connections can affect sound quality by preventing the Output components from receiving audio in time. This can manifests as clicks, pops, dropouts, and static.
Both Roon and all RAAT outputs use strategically placed memory playback buffers to limit the impact of this sort of thing, but poor performance can still lead to behavior in the CPU or networking hardware as it handles the audio stream in fits and spurts.
Invest in your server components just like you would in your other gear, and remember that there is no downside to a Core i7 with a fan if you've got it located two rooms away from the listening area. Take a look at our hardware specs, and try not to come in below our recommended level, and especially, plan on using an SSD to store Roon's databases.
Is there a reason why 6.4 only (seems) to allow a frame buffer depth of 16 as maximum? This doesn't affect the running of moOde at all but I have JRiver installed as well on 2 Pis (it is what the family are used to) and that needs a depth of 24 to display. In previous versions putting framebuffer_depth=32 in config.txt has worked however with 6.4 this doesn't (so far) and entering fbset shows 16 bit is still in effect. I have just done a fresh install of 6.3 and that still works as expected. I have done in-place updates from 6.3 to 6.4 and also a fresh install of 6.4 but haven't yet got the frame buffer depth to work. Before I do more digging I just wanted to check whether this is in fact intentional or whether there is some other way to change it in the installs I have?
The same apples to two boards, both a 3B+ and an Allo USBridge Sig. Many thanks.
Many thanks Tim!
So would the fix in your link - sudo SKIP_KERNEL=1 rpi-update - be the best option for now and/or will 6.4.1 be on a more recent kernel in any case.
After reading through I'm still not clear whether an apt-get now would update in the correct way from 6.4, sorry.
Scroll down to the desired "Bump to kernel ..." line and click on the 7 digit short hash on the right. The long hash which will be used in the rpi-update command will be listed on the right of the page.
For example "commit 16ce6121464d53a9eb9cf68afbdba7ada8ec7bcd" is for kernel 4.19.84.
