Yes, I found the best results streaming via network (both wired and wireless) from NAS. I also had excellent results using the RAM disk, but you can't fit much music on there. 🙂
I found using USB storage did not work well, even with an SSD.
Currently I am using a little RealTek USB wifi dongle (Edimax EW-7811Un - up to N150) that costs around $10 - and that works perfectly.
To make it work it's best turn off power management:
create this new file:
Code:
sudo nano /etc/modprobe.d/8192cu.confthen add this:
Code:
# Disable power management
options 8192cu rtw_power_mgnt=0reboot, and your wifi won't fall asleep on you. 🙂
Hi Russ,
I've finished Buffalo III (it's fantastic, I've already wrote in TPA forum)
Also wanted to integrate some kind of embedded platform with I2S output to feed BIII
Raspbery Pi model B and Beagle Bone black were subjects of interest.
(BBB is out of stock everywhere, i'm waiting for next batch to buy it, with additional problem to get in my country, but will find somebody who travel...)
I have some questions and what i have already found, just to summarize:
1. I think BeagleBone BLack is better as audiphile server(don't want to go into war between two platforms, i like both), just BBB have newer chip which will have longer support in linux world, and here is not yet everything polished.
2. BBB will theoretically consume less power, because of newer chip
3. It have better Ethernet, not interrupted with USB serial com
4. it has two realtime integer processor inside AM3359 running at 200MHZ , we can program it for volume control, or BIII I2C control, with no affect on music reproduction
5. Both platforms are supported as far as I know, Volumio works on both, and I2s should work
6. Develeopers at Beaglebone are trying to push as much as possbile into linux kernel for it HW, also AM3359 is much easier for support than Broadcom in Rpi
7. About DSD, there are problems at the momment, I've looked into MPD and ALSA source code, there are definitions for bitstream DSD in ALSA, but MPD is not using it, nor any music client AFAIK. MPD have DSD over PCM, which BIII doesnot support, so we should make some changes into MPD, it is not too much of work, i will do that, when i get BBB (it will work on RPI also) and try to contact ALSA dev for full integration.
If I understood you correctly, you alse have Beaglebone Black, did you try the same thing on it (Volumio) ?
Regards
I've finished Buffalo III (it's fantastic, I've already wrote in TPA forum)
Also wanted to integrate some kind of embedded platform with I2S output to feed BIII
Raspbery Pi model B and Beagle Bone black were subjects of interest.
(BBB is out of stock everywhere, i'm waiting for next batch to buy it, with additional problem to get in my country, but will find somebody who travel...)
I have some questions and what i have already found, just to summarize:
1. I think BeagleBone BLack is better as audiphile server(don't want to go into war between two platforms, i like both), just BBB have newer chip which will have longer support in linux world, and here is not yet everything polished.
2. BBB will theoretically consume less power, because of newer chip
3. It have better Ethernet, not interrupted with USB serial com
4. it has two realtime integer processor inside AM3359 running at 200MHZ , we can program it for volume control, or BIII I2C control, with no affect on music reproduction
5. Both platforms are supported as far as I know, Volumio works on both, and I2s should work
6. Develeopers at Beaglebone are trying to push as much as possbile into linux kernel for it HW, also AM3359 is much easier for support than Broadcom in Rpi
7. About DSD, there are problems at the momment, I've looked into MPD and ALSA source code, there are definitions for bitstream DSD in ALSA, but MPD is not using it, nor any music client AFAIK. MPD have DSD over PCM, which BIII doesnot support, so we should make some changes into MPD, it is not too much of work, i will do that, when i get BBB (it will work on RPI also) and try to contact ALSA dev for full integration.
If I understood you correctly, you alse have Beaglebone Black, did you try the same thing on it (Volumio) ?
Regards
I bet that if Russ created a simple and effective method for people connecting the pi/BBB to the b3se, most won't need USB for audio anymore. Just add a pi to your current bufalo dac and put the streamer/USB receiver on sale! 🙂
I am definitely still open to using the BBB.
I did use it with volumio for a while, but they were not supporting I2S out at the time. I will check again.
What's great is that even though the rpi may seem humble, it actually makes a really good streaming appliance! I am actually quite impressed. It easily beats a Squeezebox etc...
I will let you know what I find with the BBB
I did use it with volumio for a while, but they were not supporting I2S out at the time. I will check again.
What's great is that even though the rpi may seem humble, it actually makes a really good streaming appliance! I am actually quite impressed. It easily beats a Squeezebox etc...
I will let you know what I find with the BBB
The BBB has better overall specs regarding processing power and memory, which should help when dealing with large music collections and large files (eg: dsd) right?
As far as I understood for some previous post, the pi/BBB still can send dsd via i2s to the buffalo? It's not a game changer now, but as more and more people get into dsd, it would help the adoption of such systems.
The pi actually has plenty of processing power - even to do DSD. 🙂
Still I completely agree that the BBB is a far better platform.
I just happen to have the pi working right now. 🙂 And as I said, it sounds spectacular.
Still I completely agree that the BBB is a far better platform.
I just happen to have the pi working right now. 🙂 And as I said, it sounds spectacular.
Both have enough power, 512MB memory and CPU( about 10% CPU usage for audio playback)
There is more CPU demand for compressed (even lossless) files, but nothing to care about.
DSD files (both DFF and DSF) are pretty simple for playback, they are like RAW format, if they are not DST compressed. It is just reading from file, which is buffered in chunks, and minor mem copy for channel order which is simple and fast.
Current problem, maybe I'm wrong, but looking into source code of MPD client, it only support DSD over PCM (DoP) which BIII doesn't support, so there is need for additional HW FIFO buffer to remove DoP bits, or to do it in software MPD , which is much easier and better solution.
But at the moment direct DSD stream is not supported.
MPD can read DSF and DFF files but only to play it in DoP mode.
it is possible to make MPD to play DSD files over I2S in bitstream DSD and PCM files(max 24bit/192k) in PCM mode over I2s depending on the source file format, which will bIII recognize and play perfectly 🙂
I looked into MPD/ALSA code and DSD specs it is not too much work to implement it, I'm just waiting for BBB to do it with real testing.
Regards,
There is more CPU demand for compressed (even lossless) files, but nothing to care about.
DSD files (both DFF and DSF) are pretty simple for playback, they are like RAW format, if they are not DST compressed. It is just reading from file, which is buffered in chunks, and minor mem copy for channel order which is simple and fast.
Current problem, maybe I'm wrong, but looking into source code of MPD client, it only support DSD over PCM (DoP) which BIII doesn't support, so there is need for additional HW FIFO buffer to remove DoP bits, or to do it in software MPD , which is much easier and better solution.
But at the moment direct DSD stream is not supported.
MPD can read DSF and DFF files but only to play it in DoP mode.
it is possible to make MPD to play DSD files over I2S in bitstream DSD and PCM files(max 24bit/192k) in PCM mode over I2s depending on the source file format, which will bIII recognize and play perfectly 🙂
I looked into MPD/ALSA code and DSD specs it is not too much work to implement it, I'm just waiting for BBB to do it with real testing.
Regards,
Hi Tunasto,
I would be interested in working with you to get it working. It seems silly to go to DoP when there is no need. 🙂
What I would like to see is the output multiplexed on the I2S lines.
BCK -> BCK
DSD1 -> LRCK
DSD2 -> DOUT
It would also be cool to be able to swap DSD channels. 😀
I would be interested in working with you to get it working. It seems silly to go to DoP when there is no need. 🙂
What I would like to see is the output multiplexed on the I2S lines.
BCK -> BCK
DSD1 -> LRCK
DSD2 -> DOUT
It would also be cool to be able to swap DSD channels. 😀
I just sent an email to volumio and runeaudio teams inviting them to visit this thread and contribute! Let's see if they chime in!
Excellent! I will be glad if they chime in. It seems these changes to support the B3SE should be pretty simple. they could just create another DAC profile, like those that already exist.
It would also be very cool to add some dac module configs file which could be used (even with the aid of a UI) to set DAC registers via I2C and control volume as well.
This is especially handy since the B3SE needs special consideration in regard to internal DAC remapping to support the flexible I2S/DSD input scheme. The only other option is external (on the dac board in this case) control.
I hope we can work together to make it happen.
External control of the DAC could actually be looked at as a benefit if the embedded system is just another source, but if you want to to be "The Source" then hey, why not make it do the whole shebang.
Hi everyone, sorry but... tl;dr 🙂 Can anyone do me the favor to resume me in a single post what can we do for you? Not to be lazy, but I'm currently working deep in a huge rework of the RuneUI for the next 0.3-beta release, and I'm quite overwhelmed... I hope you understand.
Hi ACX,
Thanks for stopping by.
What I am personally interested in is having mpd play dsd files without conversion to DoP out to PCM(I2S) using the same pins as PCM to support the Buffalo-II/III/IIISE DACs (ES9018).
PCM out works well right now.
The output would look like this for DSD
BCK -> BCK
DSD1 -> LRCK
DSD2 -> DOUT
Thanks for stopping by.
What I am personally interested in is having mpd play dsd files without conversion to DoP out to PCM(I2S) using the same pins as PCM to support the Buffalo-II/III/IIISE DACs (ES9018).
PCM out works well right now.
The output would look like this for DSD
BCK -> BCK
DSD1 -> LRCK
DSD2 -> DOUT
I have several BBBs that I use for ham radio applications - APRS and ECHOLINK. I am very interested in using a BBB with an external DAC. I have wanted to build a B3 for a while - maybe now is the time.
Ralph
Ralph
I have to be honest and admit that I hadn't the opportunity to dig into MPD+DSD yet. We are currently working to seamlessly integrate I2S output selection in RuneUI/RuneOS, and let users choose from a list of I2S DACs for Raspberry Pi, with no configuration hassle. We can do the same for your project, but I'm not an hardware guy and I can't help a lot on configuring output for DSD. But consider me interested in this.
Really interesting!
Since the little Rpi came out, I always thought i2s was the way to go!
Talking about different platforms, both BBB and Raspberry PI have power enough to play DSD data, with a proper optimized O.S.
The pi could struggle a little more, since it suffers a lot on high bandwith transfers, for the notorious poor BUS implementation. Even if we are not relying on USB to send the data, we do need to read from it, or if we use a NAS from ethernet (which shares the same bus). So, we may face some packet loss when reading DSD files from USB or NAS, that will of course affect playback.
BBB doesn't suffer from such problems, but I must admit I didn't thought about i2s on it already.
As for MPD, you're right. It handles only dop (and it is quite logical since before the rise of i2s on rpi, the only sensible application of DSD playback was with USB DACs). And development of DSD is quite still:
master/mpd.git -
For what you want to do, I think we need at least 2 different fields to be investigated:
1- An i2s Driver which could handle direct DSD instead of using PCM, I may be wrong but this could be achieved trough mmap (don't know if that would be the most optimal solution, really). The guy that can do that is Florian Meier, as it was already mentioned.
2- A proper patch of MPD which enables direct DSD playback on the path defined by the above driver. I perfectly agree that DoP is not a solution here, direct DSD is the way. I don't have any clue on how to implement that, unfortunately.
The O.S. itself then doesn't matter too much, if the two above requirements are met. I'm really interested on get this working, and I just have a 9018 ready to go here... Just let me know how can I support that goal, and I'll be more than happy to be part of this adventure.
In case this is needed, a proper set Master Clock has to be added, since PI cannot deliver Mclk. I don't know if BBB can.
Then, my 2 cents. I recently made some serious measurements, and found out that the Imx6 platform is the one that performs better with audio playback over USB(significantly less jitter, both periodic and stochastic). In my opinion there's more than just more computing power behind that result, I want to investigate that some more. Just to be clear, imx6 platform is used in lates cubox-i models, UDOO and compulab utilites. Even if i2s protocol is substantially less jitter prone than USB, this platform could have sure some other benefits if used with i2s (but no driver seems available as of now).
I'll stick this thread in my most time favourites!
Since the little Rpi came out, I always thought i2s was the way to go!
Talking about different platforms, both BBB and Raspberry PI have power enough to play DSD data, with a proper optimized O.S.
The pi could struggle a little more, since it suffers a lot on high bandwith transfers, for the notorious poor BUS implementation. Even if we are not relying on USB to send the data, we do need to read from it, or if we use a NAS from ethernet (which shares the same bus). So, we may face some packet loss when reading DSD files from USB or NAS, that will of course affect playback.
BBB doesn't suffer from such problems, but I must admit I didn't thought about i2s on it already.
As for MPD, you're right. It handles only dop (and it is quite logical since before the rise of i2s on rpi, the only sensible application of DSD playback was with USB DACs). And development of DSD is quite still:
master/mpd.git -
For what you want to do, I think we need at least 2 different fields to be investigated:
1- An i2s Driver which could handle direct DSD instead of using PCM, I may be wrong but this could be achieved trough mmap (don't know if that would be the most optimal solution, really). The guy that can do that is Florian Meier, as it was already mentioned.
2- A proper patch of MPD which enables direct DSD playback on the path defined by the above driver. I perfectly agree that DoP is not a solution here, direct DSD is the way. I don't have any clue on how to implement that, unfortunately.
The O.S. itself then doesn't matter too much, if the two above requirements are met. I'm really interested on get this working, and I just have a 9018 ready to go here... Just let me know how can I support that goal, and I'll be more than happy to be part of this adventure.
In case this is needed, a proper set Master Clock has to be added, since PI cannot deliver Mclk. I don't know if BBB can.
Then, my 2 cents. I recently made some serious measurements, and found out that the Imx6 platform is the one that performs better with audio playback over USB(significantly less jitter, both periodic and stochastic). In my opinion there's more than just more computing power behind that result, I want to investigate that some more. Just to be clear, imx6 platform is used in lates cubox-i models, UDOO and compulab utilites. Even if i2s protocol is substantially less jitter prone than USB, this platform could have sure some other benefits if used with i2s (but no driver seems available as of now).
I'll stick this thread in my most time favourites!
Russ,
Does the Opus DAC work with the RPi and Volumio connected via I2S?
I see a switch for DSD on the Opus board. Does it engage DSD?
How does it work with respect to DSD?
Thanks,
Vince
PS. I get some pops and clicks using RPi, USB library, wireless dongle and USB DAC. Any ideas why?
I suspect the wireless. Anyone else experience this issue? With a DSD tracks, it so smooth it sounds like a vinyl record's pops and clicks.
Does the Opus DAC work with the RPi and Volumio connected via I2S?
I see a switch for DSD on the Opus board. Does it engage DSD?
How does it work with respect to DSD?
Thanks,
Vince
PS. I get some pops and clicks using RPi, USB library, wireless dongle and USB DAC. Any ideas why?
I suspect the wireless. Anyone else experience this issue? With a DSD tracks, it so smooth it sounds like a vinyl record's pops and clicks.
Last edited:
@mikelangeloz
Thanks for your interest! One thing to note is I don't need a DAC master clock (sck) because I am using the ES9018 asynchronously (100Mhz clock). I Only need bitclock, wordclock, data for PCM and bitclock and data(1 and 2) for stereo DSD. One could use a DPLL 4X clock multiplier on bitclock to generate a master clock that would work for most DACs.
Thanks for your interest! One thing to note is I don't need a DAC master clock (sck) because I am using the ES9018 asynchronously (100Mhz clock). I Only need bitclock, wordclock, data for PCM and bitclock and data(1 and 2) for stereo DSD. One could use a DPLL 4X clock multiplier on bitclock to generate a master clock that would work for most DACs.