Thank you for your donation!


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


Sound Quality in release 4.1
#21
RT or LL ? IMHO it depends on the configuration. I preferred LL Kernel with pi3-usb-waveio-i2s-buffalo DAC and RT kernel with Pi3-i2s-Dac + Pro.
Reply
#22
I would like to offer my humble 2c to the thread. I have pointed out that the 4.1 was not as clear as the 3.8. While music is mostly subjective, i have excellent ears and i did it with blind testing. 3.8 won every time (with rt i think. I remember switching between ll ant rt several times, the difference was not huge. But both were much more detailed than 4.1.
Tim contradicted my opinion back then (as is his right, nothing wrong with that) and I switched back to 3.8, coming back to the forum to see if something changed. So, I am really happy other people think the same.
My setup is rpi 2, hifiberry dec+, m-audio m3-8 active monitors
Reply
#23
(05-19-2018, 04:30 AM)Moshel Wrote: I would like to offer my humble 2c to the thread. I have pointed out that the 4.1 was not as clear as the 3.8. While music is mostly subjective, i have excellent ears and i did it with blind testing. 3.8 won every time (with rt i think. I remember switching between ll ant rt several times, the difference was not huge. But both were much more detailed than 4.1.
Tim contradicted my opinion back then (as is his right, nothing wrong with that) and I switched back to 3.8, coming back to the forum to see if something changed. So, I am really happy other people think the same.
My setup is rpi 2, hifiberry dec+, m-audio m3-8 active monitors

Hi everyone.

I am very interested in this discussion, I have the same problems and the same questions as all those who participate.
I verified the fragility of the program, when making the choice of the various configuration options shown below:

"Audio configuration":
devices
I2S - RPI-DAC audio device
And above all on "System changes":
Linux Kernel - Standard, Advanced LL, Advaced RT.
Latency level - 2 ms, 5 ms, 10 ms
Governor of the CPU: on request, performance
MPD - TS, FIFO, RR scheduler policy
 
Let me explain better, I use a homemade DAC, based on 8 Chip in parallel Burr Brown PCM1794A, so I need the I2S connection for PCM1794A DAC, I have two options for the "I2s Audio Device" Driver: RPI-DAC or DDDAC1794NOS ( the latter does not work on version 3.8.4)
 When I try to change the settings described above, to evaluate the best sound, in both versions 3.8.4 and 4.1, often something does not work and I no longer have the analogue output from the DAC. In practice, the playback page does not work anymore, sometimes I can fix it by going back to the Linux kernel - Standard, but I often have to reinstall the program on the SD card.
In addition to the REBOOT with each modification, there is a sequence to be respected when changing the parameters described above. Or it would be better to act on the program through SSH, to change these options, if this is the right way to do it, you need to know how and what you have to change.

Regarding the sound quality, according to my perception, for me in version 3.8.4 I get a greater "clarity" or less distortion of the sound, a quality undoubtedly better. The tests were done with my playback system, improved to my liking for more than ten years, to get what was my goal, high resolution audio at low levels off volume,           
system as follows:
Sony CDP XE800 CD player modified with S / PDIF digital output
In the same container, homemade: Raspberry PI 3 with MoodeAudio software,
DAC with PCM1794A with LAN, S / PDIF, I2S and USB inputs.
Music file stores: USB, 1TB HDD and LAN connection with Nas QNAP
UTC transformers for DAC / PRE interface.
Preamplifier based on 6SN7GT triodes configured as a follower of the DC coupled cathode.
 
Two YAMAHA F1030 professional mono electronic crossovers, 1100HZ 12DB cut
Two, Tubes Amplifiers stereo: SE 300B for high frequencies and PP KT88 for medium low frequencies
A direct coupled speaker system (without passive crossover) based on:
Two ESS AMT1 ribbon twiter.
Two 160 mm Supravox dynamic loudspeakers in a small, semi-enclosed volume for medium-low frequencies.
A Yamaha subwoofer for low frequencies, 80Hz 12DB cut.
 
The old version MoodeAudio 3.8.4 with KERNEL: Real-Time 4.9.41-rt30-moode1, for me, has not been surpassed by subsequent versions for the audio quality and therefore I still prefer it. This unfortunately prevents me from being able to change the Raspberry with the new 64 bit version which would not be supported.
The audio worsening occurred in the version after 3.8.4.
From ignorant I ask a question on, you can not try to insert the kernel version 3.8.4 (only the part involved in the processing of data concerning the audio part) on the new version, keeping all the other improvements made later including the possibility of using the new raspberry pi 3B +, or does it become an impossible task to do?

Thanks to everyone who wants to share and comment on my problems.
John
Reply
#24
(05-09-2018, 04:10 PM)RafaPolit Wrote:
(05-09-2018, 04:26 AM)rhizomusicosmos Wrote: Concepts such as "musical" and "veil" when applied to audio are extremely difficult to quantify and therefore troubleshoot. These subjective terms have as much to do with an individual's personal context and cognition as with anything tangible. That's not to say there aren't quantifiable triggers to these perceptions, e.g. distortion levels, sampling artifacts, EQ differences or even just a difference in overall level.

Skip is suggesting that the mid-range quality is different -- too much 'presence'. If there is a convolutional difference then this can be measured and I might be able to do this. I think I still have an SD Card with 3.8.4 on it, so I could do a comparison.

However, this won't identify what has caused the changes even if we can find a measurable difference . . .

What do people prefer: the RT or LL kernel?

-Richard

My experience was that LL was better.  From what I recall, people using external USB DACs tended to prefer the LL one, while people using internal i2s solutions overwhelmingly favored the RT Kernel.

Again, of course, just subjective appreciations and what I remember reading, so take it with a pinch of salt.

Best regards,
Rafa.

(05-29-2018, 10:06 AM)Gate45 Wrote:
(05-19-2018, 04:30 AM)Moshel Wrote: I would like to offer my humble 2c to the thread. I have pointed out that the 4.1 was not as clear as the 3.8. While music is mostly subjective, i have excellent ears and i did it with blind testing. 3.8 won every time (with rt i think. I remember switching between ll ant rt several times, the difference was not huge. But both were much more detailed than 4.1.
Tim contradicted my opinion back then (as is his right, nothing wrong with that) and I switched back to 3.8, coming back to the forum to see if something changed. So, I am really happy other people think the same.
My setup is rpi 2, hifiberry dec+, m-audio m3-8 active monitors

Hi everyone.

I am very interested in this discussion, I have the same problems and the same questions as all those who participate.
I verified the fragility of the program, when making the choice of the various configuration options shown below:

"Audio configuration":
devices
I2S - RPI-DAC audio device
And above all on "System changes":
Linux Kernel - Standard, Advanced LL, Advaced RT.
Latency level - 2 ms, 5 ms, 10 ms
Governor of the CPU: on request, performance
MPD - TS, FIFO, RR scheduler policy
 
Let me explain better, I use a homemade DAC, based on 8 Chip in parallel Burr Brown PCM1794A, so I need the I2S connection for PCM1794A DAC, I have two options for the "I2s Audio Device" Driver: RPI-DAC or DDDAC1794NOS ( the latter does not work on version 3.8.4)
 When I try to change the settings described above, to evaluate the best sound, in both versions 3.8.4 and 4.1, often something does not work and I no longer have the analogue output from the DAC. In practice, the playback page does not work anymore, sometimes I can fix it by going back to the Linux kernel - Standard, but I often have to reinstall the program on the SD card.
In addition to the REBOOT with each modification, there is a sequence to be respected when changing the parameters described above. Or it would be better to act on the program through SSH, to change these options, if this is the right way to do it, you need to know how and what you have to change.

Regarding the sound quality, according to my perception, for me in version 3.8.4 I get a greater "clarity" or less distortion of the sound, a quality undoubtedly better. The tests were done with my playback system, improved to my liking for more than ten years, to get what was my goal, high resolution audio at low levels off volume,           
system as follows:
Sony CDP XE800 CD player modified with S / PDIF digital output
In the same container, homemade: Raspberry PI 3 with MoodeAudio software,
DAC with PCM1794A with LAN, S / PDIF, I2S and USB inputs.
Music file stores: USB, 1TB HDD and LAN connection with Nas QNAP
UTC transformers for DAC / PRE interface.
Preamplifier based on 6SN7GT triodes configured as a follower of the DC coupled cathode.
 
Two YAMAHA F1030 professional mono electronic crossovers, 1100HZ 12DB cut
Two, Tubes Amplifiers stereo: SE 300B for high frequencies and PP KT88 for medium low frequencies
A direct coupled speaker system (without passive crossover) based on:
Two ESS AMT1 ribbon twiter.
Two 160 mm Supravox dynamic loudspeakers in a small, semi-enclosed volume for medium-low frequencies.
A Yamaha subwoofer for low frequencies, 80Hz 12DB cut.
 
The old version MoodeAudio 3.8.4 with KERNEL: Real-Time 4.9.41-rt30-moode1, for me, has not been surpassed by subsequent versions for the audio quality and therefore I still prefer it. This unfortunately prevents me from being able to change the Raspberry with the new 64 bit version which would not be supported.
The audio worsening occurred in the version after 3.8.4.
From ignorant I ask a question on, you can not try to insert the kernel version 3.8.4 (only the part involved in the processing of data concerning the audio part) on the new version, keeping all the other improvements made later including the possibility of using the new raspberry pi 3B +, or does it become an impossible task to do?

Thanks to everyone who wants to share and comment on my problems.
John

Hi, John, et al.

I have no dog in this fight. Neither my middling system nor my ancient ears are up to the task of detecting the kinds of differences you all are discussing, especially in casual listening.

Just so you know, there are some folks "collaborating on an official Raspberry Pi RT branch". See https://www.raspberrypi.org/forums/viewt...p?t=206747

This branch incorporates the PREEMPT_RT scheduler. They are working on kernel 4.14.y-rt.

WARNING: this is a nerdy experiment. As the collaborators say, "In particular, we have no plans to switch our kernel builds to use PREEMPT_RT or to ship them as alternative kernels."

What this means is that if you folks want to experiment on your own, here's a good place to start, but do not expect Tim to support experimental kernels. He's got way too much on his plate already. If you get it to work satisfactorily, you can create a HOWTO.

As an aside, you won't know until you've built it and listened to it whether a 4.14-rt kernel does for you what the 3.8.4-rt kernel apparently did. Be careful about expectation bias.

Regards,
Kent

PS - I almost swooned when I saw "6SN7". That venerable tube was the centerpiece of my first, amateurish foray into DIY audio back when Eisenhower was president.
Reply
#25
I was abit late to the Moodeaudio party...
I started with 3.1 and tried 3.82 - 3.84.  Not tested any of the build it yourself releases yet.

In my setup, nothing like 3.84 (with advanced real time kernel, RR & CRAAP).  This one is comfortably out of the park.

Had a listen to a few other retail solutions and came away smiling.
No more hankering for a fine audio renderer.

[Image: wooo-oh-yeah.jpg]
Reply
#26
Thanks for the reply Kent.
I looked at the link https://www.raspberrypi.org/forums/viewt...p?t=206747
Too difficult for me, to venture into things I know little.
I can not replace the Kernel from me.
If someone has the skills to do it, I'm willing to help.
If it works well, then create a HOWTO, as you suggested.
As for the 6SN7GT in particular Brimar brand, it never disappoints!
Greetings
Jon
Reply
#27
(05-02-2018, 12:02 AM)nad12 Wrote: I have been using the 3.8.4 and upgraded to 4.1 and there seems to be a veil  over the entire range  in 4.1. I have tried all the diif optimizations but
that veil does not seem to go away. I use 24/192 files  from hd tracks and all my digitized collection of cd/albums. when I put the 3.8.4 everything sounds as
musical as it was before going to 4.1. I would appreciate any any suggestions. I play back through musical fidelity dac / pre and quicksilver amps into b& w 801 with all silver wiring.


Hello all,
My name is Cor van Zundert from the Netherlands.
I have the same sound experience in MoOde 4.1 & 4.2:
Less resolution, left - right stereo has become smaller and
the music is back in the speakers instead of being in the middle of the room...

That does not mean that MoOde is doing this wrong as we have three main objects responsible for sound reproduction:

- The Operating System;
- The MPD Engine;
- The MoOde application.

Would it be possible to isolate one of the parts to diagnose the problem ??

Tim:
Would it be possible to run MoOde 4.2.1 on Debian Jessie with its own version of MPD ???

Regards,
Cor.
Reply
#28
(08-05-2018, 10:10 AM)g.vanzundert@chello.nl Wrote:
(05-02-2018, 12:02 AM)nad12 Wrote: I have been using the 3.8.4 and upgraded to 4.1 and there seems to be a veil  over the entire range  in 4.1. I have tried all the diif optimizations but
that veil does not seem to go away. I use 24/192 files  from hd tracks and all my digitized collection of cd/albums. when I put the 3.8.4 everything sounds as
musical as it was before going to 4.1. I would appreciate any any suggestions. I play back through musical fidelity dac / pre and quicksilver amps into b& w 801 with all silver wiring.


Hello all,
My name is Cor van Zundert from the Netherlands.
I have the same sound experience in MoOde 4.1 & 4.2:
Less resolution, left - right stereo has become smaller and
the music is back in the speakers instead of being in the middle of the room...

That does not mean that MoOde is doing this wrong as we have three main objects responsible for sound reproduction:

- The Operating System;
- The MPD Engine;
- The MoOde application.

Would it be possible to isolate one of the parts to diagnose the problem ??

Tim:
Would it be possible to run MoOde 4.2.1 on Debian Jessie with its own version of MPD ???

Installed versions:

O/S                   8                           9
Kernel               4.9.41                    4.14.54
MPD                  0.19.1                    0.19.21     
MoOde              3.8                         4.2.1


Regards,
Cor.
Reply
#29
(08-05-2018, 11:04 AM)g.vanzundert@chello.nl Wrote:
(08-05-2018, 10:10 AM)g.vanzundert@chello.nl Wrote:
(05-02-2018, 12:02 AM)nad12 Wrote: I have been using the 3.8.4 and upgraded to 4.1 and there seems to be a veil  over the entire range  in 4.1. I have tried all the diif optimizations but
that veil does not seem to go away. I use 24/192 files  from hd tracks and all my digitized collection of cd/albums. when I put the 3.8.4 everything sounds as
musical as it was before going to 4.1. I would appreciate any any suggestions. I play back through musical fidelity dac / pre and quicksilver amps into b& w 801 with all silver wiring.


Hello all,
My name is Cor van Zundert from the Netherlands.

I am using an RPI2B (Less noise because no Wifi & Bluetooth)
with an Allo DigiOne
Connected trough a coax cable to a Tentlabs PW DAC
With XLR Connected to Rotel RMB 100 monoblocks
which drive ELAS FS267 with 4Pi supertweeters.

I have the same sound experience in MoOde 4.1 & 4.2:
Less resolution, left - right stereo has become smaller and
the music is back in the speakers instead of being in the middle of the room...

That does not mean that MoOde is doing this wrong as we have three main objects responsible for sound reproduction:

- The Operating System;
- The MPD Engine;
- The MoOde application.

Would it be possible to isolate one of the parts to diagnose the problem ??

Tim:
Would it be possible to run MoOde 4.2.1 on Debian Jessie with its own version of MPD ???

Installed versions:

O/S                   8                           9
Kernel               4.9.41                    4.14.54
MPD                  0.19.1                    0.19.21     
MoOde              3.8                         4.2.1

In the meantime, I downgraded the kernel of MoOde 4.2.1 to version 4.9.41
with the procedure 
sudo rpi-update b9becbbf3f48e39f719ca6785d23c53ee0cdbe49


cat /proc/version now shows Linux version 4.9.41 but ..
in my opinion it did not improve the sound...

Any hints are more than welcome !

Regards,
Cor.
Reply
#30
(08-05-2018, 10:10 AM)g.vanzundert@chello.nl Wrote: Tim:
Would it be possible to run MoOde 4.2.1 on Debian Jessie with its own version of MPD ???

Regards,
Cor.

Hi Cor,

There would probably be a lot of breakage due to packages used by moOde 4 series that are not available in the Jessie repo. Other things like the boot configs for network names and so on would not work on Jessie. Also earlier versions of MPD would not work with the MPD config used in moOde 4 series. Etc, etc, etc.

Regarding the topic of whether the software influences SQ, the problem is that AFAIK no one has been able to provide any sort of reproducible analysis that proves that the software is introducing time or frequency distortion, or some other type of anomaly into the digital audio signal when the player is configured for bit-perfect transport. 

By analysis I mean something like a before and after trace of the digital signal to see if it has changed during processing by the software. I think this would at minimum require instrumenting parts of the ALSA subsystem which is beyond my expertise but if it were ever implemented then one could simply compile in the instrumented ALSA libs and then examine the b4 and after traces to see if anything changed. Then it migh be possible to isolate code thats changing the signal.

-Tim
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply


Forum Jump: