No argument from me on the changes in sound when you change settings in audio playback software. Learned that 20 years ago when playing around with some pretty simple gear on my desktop computer. It's been true on all playback software that I've used since, including Moode.
It would be easy to disagree if you've never spent any time playing with the settings.
Will say that some settings benefit some systems more than others. My current main amp/speaker combo leans towards the warm side of things and increasing buffer size or changing output mode to direct steps it too far into warm territory. Yet on another system it's just wonderful.
CPU performance seems to sound better on all the systems. So it's worth experimenting.
But the bottom line is you can make positive changes pretty easily. Thanks for pointing out so many of them.
It would be easy to disagree if you've never spent any time playing with the settings.
Will say that some settings benefit some systems more than others. My current main amp/speaker combo leans towards the warm side of things and increasing buffer size or changing output mode to direct steps it too far into warm territory. Yet on another system it's just wonderful.
CPU performance seems to sound better on all the systems. So it's worth experimenting.
But the bottom line is you can make positive changes pretty easily. Thanks for pointing out so many of them.
The purpose for the buffers is to prevent the audio from dropping out, it doesn't modify the frequency response in anyway. Think of the buffers as data buckets, the CPU will periodically keep topping up the buckets to keep them full. The contents of the buffers are simply pulled from storage media like an external disk drive or streaming site and then stored in RAM for the audio subsystem to access.
The CPU Governor has absolutely no interaction with the audio stack, the governor maintains the CPU frequency scaling to ensure the CPU is running optimally depending on system load, so it increases the frequency with a higher load and decreases the frequency on lighter loads. So its not possible by fiddling with the cpu scaler to modify the audio quality.
Changing these low level system parameters cannot possibly change the audio quality. I suggest reading about basic computing architectures before making unfounded statements about what parts of an operating system or a CPU can actually change the audio quality.
The CPU Governor has absolutely no interaction with the audio stack, the governor maintains the CPU frequency scaling to ensure the CPU is running optimally depending on system load, so it increases the frequency with a higher load and decreases the frequency on lighter loads. So its not possible by fiddling with the cpu scaler to modify the audio quality.
Changing these low level system parameters cannot possibly change the audio quality. I suggest reading about basic computing architectures before making unfounded statements about what parts of an operating system or a CPU can actually change the audio quality.
Last edited:
That's a very generous offer. Unfortunately I don't have the time, but maybe someone closer by can join?
I do spend quite some time listening at different buffer settings while working on CamillaDSP. I need to do this to check that changes I make don't prevent it from working at settings that worked before (especially in the tricky small buffer, low latency side, where also cpu governor tweaks can be helpful). I have never heard any kind of change to the sound. I only get the obvious side effects of occasional glitches when buffers get too small, or annoyingly slow responses to pausing/changing track etc when they are very large.
I do spend quite some time listening at different buffer settings while working on CamillaDSP. I need to do this to check that changes I make don't prevent it from working at settings that worked before (especially in the tricky small buffer, low latency side, where also cpu governor tweaks can be helpful). I have never heard any kind of change to the sound. I only get the obvious side effects of occasional glitches when buffers get too small, or annoyingly slow responses to pausing/changing track etc when they are very large.
I am not (yet) a Moode user. I use Volumio free version. To add to this conversation in Buffer settings and Sound Quality, Volumio has only one Buffer setting, 1MB to 12MB. I use a RPI 5 and a RPI 4, both with 8GB RAM and USB attached HDD with Hi-Res music files. Power Supply is Allo Shanti LPS.
I tried different buffer settings with my earlier DAC, viz., Topping D50S and Topping E50. There was no audible change at all.
However, with my current DAC, a Topping D90 III Discrete, the difference is night and day.
1MB Buffer setting gives me the most relaxed and analogue like sound. The sound stage is deeper. Every instrument is more textured.
With 12MB Buffer setting, the sound is harder, strident and more etched. It sounds more vivid. The height and width of the soundstage increase but the depth is all lost. The analogue, relaxed sound is no longer heard, but overall the strident sound puts you on the edge of your seat. But it is not closer to real instruments and real music, as the 1MB Buffer setting is.
All other settings between the lowest and the highest Buffer settings, lean towards the 12MB settings sound quality.
I have no idea as to why the Buffer settings make no difference with 2 of the 3 DACs I own and have tested. Internet Radio and Streaming have no dropouts even on the 1MB setting, as I have a very fast Internet connection.
I will try Moode and report. Thanks in advance.
I tried different buffer settings with my earlier DAC, viz., Topping D50S and Topping E50. There was no audible change at all.
However, with my current DAC, a Topping D90 III Discrete, the difference is night and day.
1MB Buffer setting gives me the most relaxed and analogue like sound. The sound stage is deeper. Every instrument is more textured.
With 12MB Buffer setting, the sound is harder, strident and more etched. It sounds more vivid. The height and width of the soundstage increase but the depth is all lost. The analogue, relaxed sound is no longer heard, but overall the strident sound puts you on the edge of your seat. But it is not closer to real instruments and real music, as the 1MB Buffer setting is.
All other settings between the lowest and the highest Buffer settings, lean towards the 12MB settings sound quality.
I have no idea as to why the Buffer settings make no difference with 2 of the 3 DACs I own and have tested. Internet Radio and Streaming have no dropouts even on the 1MB setting, as I have a very fast Internet connection.
I will try Moode and report. Thanks in advance.
The audio buffer does not modify the audio in anyway shape or form irrespective of its size . Its impossible for the buffer to enhance the sound stage or make the music more relaxed. The audio buffer is just a section of RAM to temporarily store data for the linux audio subsystem to load from. The buffer contains a replica of the data pulled from the source either from external storage media or from a streaming source. The buffer size will determine whether more or less of the source material data is stored in RAM.
The buffer prevents audio dropouts that maybe caused by network congestion or if the cpu is busy performing other tasks like rendering the Moode web interface. See post #16144
The Audio Buffer is upstream before any processing by the audio subsystem.
The buffer prevents audio dropouts that maybe caused by network congestion or if the cpu is busy performing other tasks like rendering the Moode web interface. See post #16144
The Audio Buffer is upstream before any processing by the audio subsystem.
@Indiglo
https://cyara.com/blog/what-is-jitter/
With a stable clock (not on demand variation) and bigger buffers there maybe are less jitter, or a different tuning of jitter overtones.
All digital signals are also analog to a certain extent since there is not anything like infinitely short rise time to any digital signal.
https://cyara.com/blog/what-is-jitter/
With a stable clock (not on demand variation) and bigger buffers there maybe are less jitter, or a different tuning of jitter overtones.
All digital signals are also analog to a certain extent since there is not anything like infinitely short rise time to any digital signal.
Last edited:
Hi,
moOde 9.3.5 is available in the Media Player OS section of the Raspberry Pi Imager or as a direct download at https://moodeaudio.org. Visit the Forum for more information https://moodeaudio.org/forum/showthread.php?tid=7726&pid=63924#pid63924
moOde 9.3.5 is available in the Media Player OS section of the Raspberry Pi Imager or as a direct download at https://moodeaudio.org. Visit the Forum for more information https://moodeaudio.org/forum/showthread.php?tid=7726&pid=63924#pid63924
I mostly post on this thread or the moode forum when I have an issue, now that’s not really fair but it highlights how important moode is to my audio system and experience. For years I only have 2 sources vinyl and moode, as of now I’ve had 3-4 in-place updates in a row work perfectly and I’ve had good, consistent Bluetooth functionality over the same period. No issues just want to say Thanks Tim
What is the CURRENT username and password for ssh into the command line? I jave tried pi, moode, moodeaudio etc etc and also the password I set up when I imaged the SD card. All are permission denied. I have answered "yes" when the terminal message about trusting the host. I have tried deleting the /Users/<me>/.ssh/ file and this resets that question when I try a new username....
Trying to mount a NAS via an apple airport extreme, this share is visible to the Mac I am using, with hostIP/Share path or cifs://hostIP/Share.
I have read elsewhere that a package needs to be installed for cifs and that ssh needs to be used to install the package. So far no luck.
Same problem using this pi 4B, booted into Volumio or Moode. So I'm clearly doing something wrong but my internet searching has not turned up what, exactly, that is.
Getting frustrated. Anybody have any ideas please?
Trying to mount a NAS via an apple airport extreme, this share is visible to the Mac I am using, with hostIP/Share path or cifs://hostIP/Share.
I have read elsewhere that a package needs to be installed for cifs and that ssh needs to be used to install the package. So far no luck.
Same problem using this pi 4B, booted into Volumio or Moode. So I'm clearly doing something wrong but my internet searching has not turned up what, exactly, that is.
Getting frustrated. Anybody have any ideas please?
If you followed the Setup Guide then its the userid and password you entered in the Raspberry Pi imager.
https://github.com/moode-player/docs/blob/main/setup_guide.md#setup-guide-
https://github.com/moode-player/docs/blob/main/setup_guide.md#setup-guide-
Well, indeed it is. I had changed it from what I THOUGHT I had put and only just now found wehere I wrote it down.
Thanks!
Thanks!
What a wondrous way graphite and papyrus et al has helped and continues to ... vs our sometimes faulty memory and often our faulty process committing information to and finding it from electronic devices.
Great it is now working for you and you're up and running with MoOde. 🙂
Great it is now working for you and you're up and running with MoOde. 🙂
Nope. The size of the RAM cache ( the audio buffers you speak of ) has nothing to do with the clocking of the data within the DAC.
The DAC has its own clock and likely runs a DMA anyhow to fetch data from the RAM cache to the internal DAC cache.
Writing into the RAM cache buffers is not under the DAC but under the software that is streaming the music. The idea is that when the RAM cache buffer starts to run low, the streamer software will issue a request to the upstream source for more data - most likely by controlling the back pressure regulation on the network layer - or making a request to an internal device (CD or file system ).
Source ( via streamer SW)-> RAM cache
The DAC on its own will fetch the data from the RAM cache without any help from the streamer software. Current designs use the DMA. That data is then stored into a DAC cache.
RAM cache -> DAC cache
Within the DAC, the audio data in the DAC cache is then fetched processing with its own internal clock.
DAC cache -> DAC renderer
The transfers in and out of RAM cache are initiated via an interrupt. When you tweak the "buffer size" you are most likely setting the conditions that trigger the interrupt to command the data transfers into RAM cache. I doubt that you have control over the size of the DAC's internal cache.
...
What the size of the RAM cache does is to apply back pressure to the source of the digital data via the streamer connection upstream ( could be an IP network, USB, Bluetooth, Firewire, etc...).
....
If for some reason the DAC cache were to run empty... , well, you get a sound cut off.
Last edited:
@tonyEE
I'm not talking about the clock in the DAC.
I talk about the clock in the Raspberry Pi and the re-clocker in the I2S transport which in my case is Allo Digione.
It is these clocks that handle loading and unloading of the caches, and to prevent jitter these need to be very accurate to be able to keep the I2S transfer free from jitter.
You are not the first that mention the DAC's clock.
That is not an issue at all, and my Mark Levinson No 360S has it's own reclocking too remove eventual jitter, but still caches sizes and setting the Pi's clock to fixed max speed have quite a big impact on sound quality. Why do they?
I'm not talking about the clock in the DAC.
I talk about the clock in the Raspberry Pi and the re-clocker in the I2S transport which in my case is Allo Digione.
It is these clocks that handle loading and unloading of the caches, and to prevent jitter these need to be very accurate to be able to keep the I2S transfer free from jitter.
You are not the first that mention the DAC's clock.
That is not an issue at all, and my Mark Levinson No 360S has it's own reclocking too remove eventual jitter, but still caches sizes and setting the Pi's clock to fixed max speed have quite a big impact on sound quality. Why do they?
We can also add to this operation, internally at the hardware level the processor has a dedicated external memory controller (RAM) under the control of the internal system bus and cpu cores.
Exactly, in simple terms its notifying the cpu cores to fill the bucket (Moode Audio Buffer) because its almost empty.
^ "at the hardware level the processor has a dedicated external memory controller (RAM) under the control of the internal system bus and cpu cores..."
That's the DMA ( Direct Memory Access ). You program it with microcode and it handles the transfers over the address/memory buss to different addresses ( devices ).
So, if a device wants to make a big transfer of data, it just makes a call to the DMA device driver, then the microcode is loaded into the DMA and a start command is given.
While the data is being transferred, the cores can keep doing work so long as they don't try to access the memory buss ( they can use core cache )...
That's the DMA ( Direct Memory Access ). You program it with microcode and it handles the transfers over the address/memory buss to different addresses ( devices ).
So, if a device wants to make a big transfer of data, it just makes a call to the DMA device driver, then the microcode is loaded into the DMA and a start command is given.
While the data is being transferred, the cores can keep doing work so long as they don't try to access the memory buss ( they can use core cache )...
You know... there are TONS of clocks all over the place...
The I2S operates on its own clocks as well... it's a peripheral device.
Jitter... buffers.... heck right now I'm programming an IO device that takes data to/from internet. It has buffers as well, and it's own clocks. The data is very important as it keeps an airplane from falling out of the sky.
Explain to me, in engineering terms, how buffers and clocks affect the I2S transfers. Don't give it to me in generic terms.
Explain to me how the size of a buffer affects jitter ( never mind the choice of RTOS and software architecture )...
Specify which buffers are you talking about.
Is the software running a single loop ( bad... ) or did they write it multithreaded-multiprocess with interrupt handling ( like we did with the Raspberries in two of my previous jobs ).
Did it ever dawned to you that the software architecture may have a lot to do with why it needs high speeds? We were programming SoC ten years ago that had absolutely no issues with jitter and buffer size.... we used Android Kernel.. and we Raspberries for some early testing... again, there was NO issue between the buffer size and jitter. All of that hardware used ARM M, R and A cores. And, hmm.. yeah... BCM was signing my paychecks then, so we sort of knew quite a bit about that particular berry platform.
We used a multithreaded design and used interrupts to command the DMA to do all data transfers larger than 128 bytes.
Look, I've been doing device drives in firmware since the late 70s... OK? Oh yeah, I've programmed I2S devices too.. running under.... Android -kernel- and ThreadX.
You're just looking at this as an user. Fine with me, but don't make ridiculous claims.
Adios. My phono preamp is warming up today.
Last edited: