05-15-2018, 12:36 PM
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.
Thank you for your donation!
Sound Quality in release 4.1
|
05-15-2018, 12:36 PM
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.
05-19-2018, 04:30 AM
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
05-29-2018, 10:06 AM
(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. 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
05-29-2018, 12:24 PM
(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. (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. 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.
05-29-2018, 12:43 PM
(This post was last modified: 09-02-2018, 10:32 AM by hifix.
Edit Reason: long story
)
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.
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
08-05-2018, 10:10 AM
(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 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.
08-05-2018, 11:04 AM
(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
08-05-2018, 12:31 PM
(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
08-05-2018, 05:20 PM
(08-05-2018, 10:10 AM)g.vanzundert@chello.nl Wrote: Tim: 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 |
« Next Oldest | Next Newest »
|