It could be made to work, but it would require some engineering. For instance I would need to generate a suitable system clock. The ES9018 does not need that.
Errrrr.... yes, I believe I did. Sorry - it was late.
I edited the post to fix it. Thanks for helping me clear that up.
Last edited:
BBB looks more promising for HQ audio playback, because of internal design and newer chip, but i think we can make it to work for any platform the same if that platform has drivers for I2S.
path for both DSD and PCM should be:
audio client (MPD) -> ALSA SoC -> I2S -> DAC
ALSA SOC driver for I2S for Rpi was implemented by Florian Meier, just need to add this during kernel compilation for RPI distro (already done in Volumio)
The same driver for BBB already exist in linux kernel, it is tested by TI, also just need to be added during Linux Kernel Config prior compilation for BBB distro
(if i understood correctly it is not yet done in Volumio)
ALSA driver has definition for both DoP and bitstream(RAW) DSD.
DoP already work from MPD.
For RAW DSD in ALSA SND_PCM_FORMAT_DSD_U16 is need to be set during snd_pcm initialisation in snd_pcm_hw_params_set_format.
Audio client (MPD) should do this
(at the moment MPD is not using this)
Volumio and Rune should just add latest ALSA driver in distribution.
(maybe it is already there)
This Enum is added during 2013, not sure exact time.
If there are any problems in ALSA implementation for this, I can talk with them for changes, they are not having system for DSD playback we are talking here, so it is not fully tested AFAIK.
And input from here is welcome for them for sure.
Until here I think we dont have anything to work on, just to include and compile kernel for both Distros Rpi and BBB (VOlumio, RuneAudio,...)
----
Audio client doesn't have support for direct DSD stream to alsa driver.
for first iteration i would suggest that we implement simple dff/dfs Test player. than to make MPD work, and contact MPD developers to include it in their source tree.
Client is simple, it should configure ALSA snd_pcm, read from file, jump over header, reorder bytes a little, then call snd_pcm_writei()
file order is CH1_0, CH2_0, CH1_1, CH2_1, Ch1_2, CH2_2 ,....
it should be ordered CH1_0, CH1_1,CH2_0, CH2_1,Ch1_2, Ch1_3, CH2_2, CH2_3,...
That's it
I can make code for this, need to make Linux dev enverionment.
I just cant test it on BBB nor RpI, i dont have them.
----
Sorry for longer post, i cant fully make this at the mommnet (waiting for BBB), so i'm trying to give you as much as i was investigated.
And this should be important, i have looked into specs for format, linux kernel dev, source code...
I didnt try anything of this, just theory...ok i'm software architect and was contributed in linux kernel for some drivers, so i hope i understand just a little
Regards,
path for both DSD and PCM should be:
audio client (MPD) -> ALSA SoC -> I2S -> DAC
ALSA SOC driver for I2S for Rpi was implemented by Florian Meier, just need to add this during kernel compilation for RPI distro (already done in Volumio)
The same driver for BBB already exist in linux kernel, it is tested by TI, also just need to be added during Linux Kernel Config prior compilation for BBB distro
(if i understood correctly it is not yet done in Volumio)
ALSA driver has definition for both DoP and bitstream(RAW) DSD.
DoP already work from MPD.
For RAW DSD in ALSA SND_PCM_FORMAT_DSD_U16 is need to be set during snd_pcm initialisation in snd_pcm_hw_params_set_format.
Audio client (MPD) should do this
(at the moment MPD is not using this)
Volumio and Rune should just add latest ALSA driver in distribution.
(maybe it is already there)
This Enum is added during 2013, not sure exact time.
If there are any problems in ALSA implementation for this, I can talk with them for changes, they are not having system for DSD playback we are talking here, so it is not fully tested AFAIK.
And input from here is welcome for them for sure.
Until here I think we dont have anything to work on, just to include and compile kernel for both Distros Rpi and BBB (VOlumio, RuneAudio,...)
----
Audio client doesn't have support for direct DSD stream to alsa driver.
for first iteration i would suggest that we implement simple dff/dfs Test player. than to make MPD work, and contact MPD developers to include it in their source tree.
Client is simple, it should configure ALSA snd_pcm, read from file, jump over header, reorder bytes a little, then call snd_pcm_writei()
file order is CH1_0, CH2_0, CH1_1, CH2_1, Ch1_2, CH2_2 ,....
it should be ordered CH1_0, CH1_1,CH2_0, CH2_1,Ch1_2, Ch1_3, CH2_2, CH2_3,...
That's it
I can make code for this, need to make Linux dev enverionment.
I just cant test it on BBB nor RpI, i dont have them.
----
Sorry for longer post, i cant fully make this at the mommnet (waiting for BBB), so i'm trying to give you as much as i was investigated.
And this should be important, i have looked into specs for format, linux kernel dev, source code...
I didnt try anything of this, just theory...ok i'm software architect and was contributed in linux kernel for some drivers, so i hope i understand just a little
Regards,
Probably many people know about this, just to put refernces for easier track.
for BBB TI have page for Audio on AM335x
AM335x Audio Driver's Guide - Texas Instruments Wiki
it is good help
Angstrom distro already have compiled everything for I2S to work on BBB.
Here are two pages that go slithly into implementation.
BeagleBone Black: BBB - Audio notes | element14
BeagleBone Black: BBB - Building a DAC | element14
Anything about DSD, just PCM playback over I2S
Regards,
for BBB TI have page for Audio on AM335x
AM335x Audio Driver's Guide - Texas Instruments Wiki
it is good help
Angstrom distro already have compiled everything for I2S to work on BBB.
Here are two pages that go slithly into implementation.
BeagleBone Black: BBB - Audio notes | element14
BeagleBone Black: BBB - Building a DAC | element14
Anything about DSD, just PCM playback over I2S
Regards,
Russ, I understand that you're taking I2S straight off the Pi's processor.
Prior to this, did you try a USB-to-I2S interface to the Pi? In particular, one of the well-regarded ones; Combo384, WaveIO, or Audio-Widget?
I'm wondering about the relative SQ, which would be all the more interesting given your situation of using the same front-end hardware/OS in both instances.
Your direct-I2S regime is certainly more technically direct, but I don't automatically assume this means better SQ ...
however, if it does ultimately beat USB-I2s, then this is really a game-changer.
Prior to this, did you try a USB-to-I2S interface to the Pi? In particular, one of the well-regarded ones; Combo384, WaveIO, or Audio-Widget?
I'm wondering about the relative SQ, which would be all the more interesting given your situation of using the same front-end hardware/OS in both instances.
Your direct-I2S regime is certainly more technically direct, but I don't automatically assume this means better SQ ...
however, if it does ultimately beat USB-I2s, then this is really a game-changer.
Yes - I have tested many USB devices, even my own.
There is no technical reason even an asynchronous USB module should be better, *unless* the processor itself is clocked by the audio master clock. I don't know of any that are.
In any case my opinion is that a USB module is added complexity that I have found is absolutely not required, and adds zero *actual* benefit in my experience - especially with a DAC like ours that is Asynchronous. In any case such an approach is not the topic at hand, and I am not really interested in pursuing USB at the moment.
There is no technical reason even an asynchronous USB module should be better, *unless* the processor itself is clocked by the audio master clock. I don't know of any that are.
In any case my opinion is that a USB module is added complexity that I have found is absolutely not required, and adds zero *actual* benefit in my experience - especially with a DAC like ours that is Asynchronous. In any case such an approach is not the topic at hand, and I am not really interested in pursuing USB at the moment.
I were in Audioreview's test lab last week. We used an Audioprecision appliance to measure jitter. The testing methodology consists in sending both high (0db) and low (-70db) audio signals, and compare them.
Imx6 (UDOO) values of jitter were significantly lower with same USB DAC (receiver XMOS2, DAC Sabre 9023) than other platforms. I didn't test SPDIF.
I am writing an article on that findings, which will be published on AudioReview of March. I'll share with you when this comes out
There are lots of reasons which make i2s preferrable over USB, in audio domain at least. You can find a simple explanation here:
i2s DACS on Raspberry PI
I personally tried Amanero and XMOS2 based USB receivers. While SQ is mostly affected by DAC chip itself (and its implementation, of course), on paper I2S is the better solution.
I found something really interesting, while measuring Volumio's performances (read posts above). While using i2s, jitter was not affected by changes in O.S. parameters. Using Ramplay, software mixer or different resampling methods was resulting in comparable jitter values.
That was not true with USB, changing parameters above had significant impacts on jitter values.
So, my point is, USB is OK. I2S is the way to go for the highest SQ. And since these devices offer that chance, why not using that??
sorry for OTs...
To remain IT,
@tunasto
I will push the developement of Volumio in the direction you guys are suggesting. It seems the best way to go. So, in order:
1- Next BBB release will feature latest alsa driver and a kernel compiled with i2s support. If the modules are already in the mainline git, it won't require too much.
If we do need special alsa driver, we can also recompile alsa for that purpose, but this will increase development times, since we may encounter some stability issues.
2- We can try to look at MPD code and see if there is an effective and quick solution on that. For that we can create a fork on Volumio's github, which mirrors MPD one. I'll start setting this up.
3- If you guys need a dev environment I can prepare a dev image for BBB which you could use to test and compare results. In my opinion using a Virtual Machine doesn't help in audio development, since we need to see the actual behaviour of drivers and alsa subsystem.
What you think? Is there anything more I can do to support this?
To remain IT,
@tunasto
I will push the developement of Volumio in the direction you guys are suggesting. It seems the best way to go. So, in order:
1- Next BBB release will feature latest alsa driver and a kernel compiled with i2s support. If the modules are already in the mainline git, it won't require too much.
If we do need special alsa driver, we can also recompile alsa for that purpose, but this will increase development times, since we may encounter some stability issues.
2- We can try to look at MPD code and see if there is an effective and quick solution on that. For that we can create a fork on Volumio's github, which mirrors MPD one. I'll start setting this up.
3- If you guys need a dev environment I can prepare a dev image for BBB which you could use to test and compare results. In my opinion using a Virtual Machine doesn't help in audio development, since we need to see the actual behaviour of drivers and alsa subsystem.
What you think? Is there anything more I can do to support this?
No worries, sorry if I came off rude. Was not intended.
I think this is spectacular! I am really juiced to get rolling.
I've got from a friend direction.
Here is simple DSD player (~200 lines of code), only DFF files, using mentioned ALSA definitions for direct DSD playback.
It is written by Daniel Mack, one of the ALSA developers.
https://github.com/zonque/alsa-dsd-player
We now have all pieces for testing, just need distro with latest ALSA driver and included ALSA SoC for specific platform which support I2S.
I would like first to make it work this way, with simple player, than to go into MPD.
Regards,
D.
Here is simple DSD player (~200 lines of code), only DFF files, using mentioned ALSA definitions for direct DSD playback.
It is written by Daniel Mack, one of the ALSA developers.
https://github.com/zonque/alsa-dsd-player
We now have all pieces for testing, just need distro with latest ALSA driver and included ALSA SoC for specific platform which support I2S.
I would like first to make it work this way, with simple player, than to go into MPD.
Regards,
D.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.