Jump to content
IGNORED

New Raspberry Pi Model B+


Recommended Posts

I'm sure you already have your mpd clients sorted, but if not then 'mpc' is very scriptable, whilst MPoD (for iPod) is very convenient and user-friendly.

Front End: Neet Airstream

Digital Processing: Chord Hugo M-Scaler

DAC: Chord Dave

Amplification: Cyrus Mono x300 Signatures

Speakers: Kudos Titan T88

Link to comment

Have you ever tried ... An UPnP Audio Media Renderer based on MPD ... to interface MPd to a UPnP control point and server?

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

It's a bit difficult to see exactly what you've changed by looking at the entire file. There is a Linux tool called 'diff' which shows the differences between two text files - you can type 'diff mpd.conf.orig mpd.conf' if the original file was mpd.conf.orig.

 

I've tried increasing the read buffering percentage, like you've increased it to 50%, but it has always made things worse with a lengthy pause while it reads half a track before it plays. I prefer the default setting which does a little reading often.

System (i): Stack Audio Link > 2Qute+MCRU psu; Gyrodec/SME V/Hana SL/EAT E-Glo Petit/Magnum Dynalab FT101A) > PrimaLuna Evo 100 amp > Klipsch RP-600M/REL T5x subs

System (ii): Allo USB Signature > Bel Canto uLink+AQVOX psu > Chord Hugo > APPJ EL34 > Tandy LX5/REL Tzero v3 subs

System (iii) KEF LS50W/KEF R400b subs

 

Link to comment
It's a bit difficult to see exactly what you've changed by looking at the entire file. There is a Linux tool called 'diff' which shows the differences between two text files - you can type 'diff mpd.conf.orig mpd.conf' if the original file was mpd.conf.orig.

 

I've tried increasing the read buffering percentage, like you've increased it to 50%, but it has always made things worse with a lengthy pause while it reads half a track before it plays. I prefer the default setting which does a little reading often.

 

Yeah, it's probably only the buffering that shows much in the way of changes - this is what works for me. I've got about 10 mpd.conf files which I have played around with over the course of a few months in spare moments, e.g. trying out the extra parameters for the 'audio_output' section, I have probably ended up returning to original settings through finding that most of the changes made no appreciable difference. I wasn't very scientific about it, given the lack of guiding documentation.

 

So where I wrote "a fair amount of tweaking around", I should have more accurately written "tweaking around to see what made a difference and what didn't".

 

Oddly, I don't get any noticeable pause for the 50% buffering as you do. I get two quick drop-outs on startup every time - like clockwork - when it initially buffers on MPD startup, but I never, ever get any pause or dropout after that.

 

Do you know of any good MPD documentation for its configuration? I have in the past hunted around the internet for some to no avail. It would be good to know what all these settings precisely do without having to delve into the MPD code itself. If enough people are interested, I could do just that for particular settings, but I'm not going to burn the time otherwise.

Front End: Neet Airstream

Digital Processing: Chord Hugo M-Scaler

DAC: Chord Dave

Amplification: Cyrus Mono x300 Signatures

Speakers: Kudos Titan T88

Link to comment
Have you ever tried ... An UPnP Audio Media Renderer based on MPD ... to interface MPd to a UPnP control point and server?

 

No I haven't, and I wasn't aware of it.

 

I'll take a look at it. Hopefully there is a version for the ARM architecture.

Front End: Neet Airstream

Digital Processing: Chord Hugo M-Scaler

DAC: Chord Dave

Amplification: Cyrus Mono x300 Signatures

Speakers: Kudos Titan T88

Link to comment
It works on the new B+.

 

Great! I (naively) assume it should work on my older Pi platform too.

 

It would be great if we can get some sort of Pi community working together, so we can all help each other with tasks.

 

I would love, for instance, to have a working GPIO 12S interface.

 

I've personally managed to wire up an LCD to the GPIO and build some kludgy python scripts to scroll the songs which are playing, but I'm afraid it doesn't add any sonic benefits! (probably the opposite!). It was a fun exercise though. Still have the soldering burn marks... :)

Front End: Neet Airstream

Digital Processing: Chord Hugo M-Scaler

DAC: Chord Dave

Amplification: Cyrus Mono x300 Signatures

Speakers: Kudos Titan T88

Link to comment

It is pretty easy as long as you do not need a mclk signal. Many ESS 9023 and 9018 implementations have async in and use their own clocks. PiCorePlayer, Volumio and Rune provide code to turn it on. A 9023 board can be had for cheap (<$20) and I2S is available on the P1 header next to the GPIO one.

I would love, for instance, to have a working GPIO 12S interface.

Forrest:

Win10 i9 9900KS/GTX1060 HQPlayer4>Win10 NAA

DSD>Pavel's DSC2.6>Bent Audio TAP>

Parasound JC1>"Naked" Quad ESL63/Tannoy PS350B subs<100Hz

Link to comment
It is pretty easy as long as you do not need a mclk signal. Many ESS 9023 and 9018 implementations have async in and use their own clocks. PiCorePlayer, Volumio and Rune provide code to turn it on. A 9023 board can be had for cheap (<$20) and I2S is available on the P1 header next to the GPIO one.

 

Thanks, really good to know. I would probably try to tap it into the existing ESS chip on my EE MiniMax but I strongly suspect that I might be biting off more than I can chew.

 

Playing devil's advocate somewhat: given that the ESS chips manage S/PDIF asynchronously, i.e. they dump the incoming clock data, then what makes the I2S feed materially better? I can understand that it is more 'native', but what is to be gained if the chip itself is actually (re-)clocking the L/R word data?

 

I should point out that I'm not trying to be clever here, I'm just keen to learn more!

Front End: Neet Airstream

Digital Processing: Chord Hugo M-Scaler

DAC: Chord Dave

Amplification: Cyrus Mono x300 Signatures

Speakers: Kudos Titan T88

Link to comment

There are still noticeable advantages. A mclk in would be preferred if the clock were a good one. In this instance, we are avoiding the aforementioned USB bus issues and not combining (multiplexing) the mclk, L/R clk, bit clk and data. Once combined, it is impossible to completely separate them from each other. I2s is not automatically better in all instances, but with all other things equal, it often is.

 

Building an open embedded audio applicance. - diyAudio

 

Thanks, really good to know. I would probably try to tap it into the existing ESS chip on my EE MiniMax but I strongly suspect that I might be biting off more than I can chew.

 

Playing devil's advocate somewhat: given that the ESS chips manage S/PDIF asynchronously, i.e. they dump the incoming clock data, then what makes the I2S feed materially better? I can understand that it is more 'native', but what is to be gained if the chip itself is actually (re-)clocking the L/R word data?

 

I should point out that I'm not trying to be clever here, I'm just keen to learn more!

Forrest:

Win10 i9 9900KS/GTX1060 HQPlayer4>Win10 NAA

DSD>Pavel's DSC2.6>Bent Audio TAP>

Parasound JC1>"Naked" Quad ESL63/Tannoy PS350B subs<100Hz

Link to comment
There are still noticeable advantages. A mclk in would be preferred if the clock were a good one. In this instance, we are avoiding the aforementioned USB bus issues and not combining (multiplexing) the mclk, L/R clk, bit clk and data. Once combined, it is impossible to completely separate them from each other. I2s is not automatically better in all instances, but with all other things equal, it often is.

 

Building an open embedded audio applicance. - diyAudio

 

Yep, very good point about the external clock. Thanks.

 

Do you know how the failure to separate the different multiplexed channels on the S/PDIF feed might manifest itself? (Sorry, more questions!) I know if, using a hex editor, I manually alter even one sample of a Redbook pcm file, I can hear the resulting click. It's really obvious. Since I don't hear any clicks with my current system topology, I have always assumed that the L/R word data was been correctly extracted from the interleaved S/PDIF signal by the relevant elements within the EE DAC. I guess subtler things are at play?

Front End: Neet Airstream

Digital Processing: Chord Hugo M-Scaler

DAC: Chord Dave

Amplification: Cyrus Mono x300 Signatures

Speakers: Kudos Titan T88

Link to comment

There is much discussion about this, and I am not qualified to speak directly about it- besides, it is off topic. Look into threads about async USB vs SPDIF and you will get a start. Loosely, when signals are mixed, they cause beat frequencies associated with the sums and differences of the two signals. These beat frequencies can be in the audio band or create jitter in the RF (mclk) range that the digital system needs to ameliorate. To date IME, lower jitter always manifests itself in better sound. I2S is not a panacea either. I will take great SPDIF over bad I2S any day...

Yep, very good point about the external clock. Thanks.

 

Do you know how the failure to separate the different multiplexed channels on the S/PDIF feed might manifest itself? (Sorry, more questions!) I know if, using a hex editor, I manually alter even one sample of a Redbook pcm file, I can hear the resulting click. It's really obvious. Since I don't hear any clicks with my current system topology, I have always assumed that the L/R word data was been correctly extracted from the interleaved S/PDIF signal by the relevant elements within the EE DAC. I guess subtler things are at play?

Forrest:

Win10 i9 9900KS/GTX1060 HQPlayer4>Win10 NAA

DSD>Pavel's DSC2.6>Bent Audio TAP>

Parasound JC1>"Naked" Quad ESL63/Tannoy PS350B subs<100Hz

Link to comment
There is much discussion about this, and I am not qualified to speak directly about it- besides, it is off topic. Look into threads about async USB vs SPDIF and you will get a start. Loosely, when signals are mixed, they cause beat frequencies associated with the sums and differences of the two signals. These beat frequencies can be in the audio band or create jitter in the RF (mclk) range that the digital system needs to ameliorate. To date IME, lower jitter always manifests itself in better sound. I2S is not a panacea either. I will take great SPDIF over bad I2S any day...

 

Thanks, yeah it's OT so I'll go look elsewhere for information.

 

I work in digital telecommunications so I'm very interested to learn about some of these items beyond my knowledge base. I'm quite skeptical in nature about some claims made in the digital domain - I spent nearly an hour yesterday with my local hifi salesman arguing the theoretical aspects of Ethernet vs his unshakeable belief that Cat 5/6/7 cable differentiation plays a role in hifi - but if people can repeatedly identify a difference from listening tests then there clearly is something going on.

 

But this is OT, so I'll restrict my comments now to the Pi.

Front End: Neet Airstream

Digital Processing: Chord Hugo M-Scaler

DAC: Chord Dave

Amplification: Cyrus Mono x300 Signatures

Speakers: Kudos Titan T88

Link to comment

I am just trying to stay out of trouble with the management! ;)

 

Feel free to PM me, but know that this is not at all like a sub vs obj digital cable debate. The physics is real and acknowledged by most that understand it. I2S is used in most dacs between the USB receiver and the DAC chip. It does not, and was not meant to connect boxes together, but works great as an internal connection ala the RasPi.

 

I'm quite skeptical in nature about some claims made in the digital domain.

Forrest:

Win10 i9 9900KS/GTX1060 HQPlayer4>Win10 NAA

DSD>Pavel's DSC2.6>Bent Audio TAP>

Parasound JC1>"Naked" Quad ESL63/Tannoy PS350B subs<100Hz

Link to comment
  • 4 weeks later...

Just got a new Debian Wheezy instance up and running on a 128Gb SD card. For some reason I thought it might not be possible on a large SDXC card and hadn't tried before, but it is - and all that storage can be made available with a single click on first boot.

 

My music collection is approx. 100Gb, which I will now copy over from my NAS to the SD card.

 

So no more Ethernet cable. :)

 

I've replaced the wall wart with a battery pack to power the RPi, so it's a nice little standalone unit now. If I weren't using Toslink I would be quite excited about the galvanic isolation. :)

Front End: Neet Airstream

Digital Processing: Chord Hugo M-Scaler

DAC: Chord Dave

Amplification: Cyrus Mono x300 Signatures

Speakers: Kudos Titan T88

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...