I2S sound: Anyone got it running? (answer is yes!)


595 posts   Page 12 of 24   1 ... 9, 10, 11, 12, 13, 14, 15 ... 24
by Sniper435 » Wed May 01, 2013 9:37 am
Greetings,

I've been watching this thread for quite a while now in anticipation of a working I2S driver for a project I'm working on.
could either Philpoole or koalo fill me in with what changes or driver options need to be supplied to run the Pi as an I2S slave? From what I understand (and more importantly what my collaborator and hardware wizard understands) we're all set up in terms of supplying the correct clock to the Pi (we are using a DIR9001 with an external crystal to generate and supply the clocks both for the pi and for the DACS which are PCM5141) ideally we want to be able to run at 48KHz and 24bits.

Any help on this would be much appreciated, and thanks so much for all your work on getting some drivers out there.
Posts: 17
Joined: Fri Nov 02, 2012 1:35 pm
by koalo » Wed May 01, 2013 10:09 am
Sniper435 wrote:could either Philpoole or koalo fill me in with what changes or driver options need to be supplied to run the Pi as an I2S slave?


With the ASoC driver it is quite easy - you only have to specify the correct format in the machine driver. I can help you to build a machine driver, but first I have to understand your setup:

Sniper435 wrote:From what I understand (and more importantly what my collaborator and hardware wizard understands) we're all set up in terms of supplying the correct clock to the Pi (we are using a DIR9001 with an external crystal to generate and supply the clocks both for the pi and for the DACS which are PCM5141) ideally we want to be able to run at 48KHz and 24bits.


Why are you using a DIR9001 as well as a PCM5141? Are you using the DIR9001 only for clock generation (this seems bloated - even if you want to use an external clock) or is there anything else that this chip does for you?
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by Sniper435 » Wed May 01, 2013 10:21 am
essentially the system isn't just the pi and a dac..
what we've got is a little more complex..
essentially we're building a digital crossover with multiple selectable inputs of which the pi is just one..
we also have optical and coaxial digital inputs via the DIR9001 and analogue inputs via a PCM1518A, the DIR9001 is supplying the I2S clocks for everything and we have a 3:1 i2s data switch for choosing which i2s source is going to the DACs (multiple dacs due to it being a digital crossover)

as well as acting as an audio source (plan is to use mpd) the pi will also be controlling the DACs and various input selections via I2C, controllable via a few buttons, a rotary encoder and a small OLED screen...

hopefully that gives you a bit more idea what we're doing :)
Posts: 17
Joined: Fri Nov 02, 2012 1:35 pm
by koalo » Wed May 01, 2013 10:48 am
That sounds nice!

The main thing you have to think about is how you want to integrate ASoC/ALSA. There are different options:
1.) Don't use the control features of ALSA. This means you use the ALSA system only for supplying the I2S stream and handle all controls (I2C etc.) externally. This would require a dummy codec and machine driver.
2.) Build your whole system structure in ALSA. This would be a clean solution, because all controls would be available in alsamixer (and therefore in higher layers), but it would require some more thoughts about how to represent such a complex system within the ASoC structure.
3.) Build only the DAC interfaces in ALSA. From ALSA this would seem like you connect the DACs in parallel to the Raspberry Pi without a switch in between. This would at least provide the possibility to control the DAC features (volume etc.) via alsamixer.
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by Sniper435 » Wed May 01, 2013 10:53 am
I think due to the complexity of our setup and our ideas for how we plan on controlling everything the best option will be the first one, a dummy codec and machine driver. this seems like the easiest to get going an would allow us to test the pi's i2s in our setup. maybe further down the line I'll want to investigate the second option but atm that's probably way over my head.
Posts: 17
Joined: Fri Nov 02, 2012 1:35 pm
by koalo » Wed May 01, 2013 11:07 am
Ok - in that case I will upload the driver for the TDA1541A soon. It is more or less a dummy codec (it features no controls). Then I will guide you on how to change the driver to fit your needs.

Are you familiar with kernel compilation for the raspberry pi?
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by Sniper435 » Wed May 01, 2013 11:25 am
I've not played with compiling kernels for the pi yet - if you could point me to any helpful documents for setting up to cross compile on a ubuntu system then I can probably handle it, I'll look into it and see if I can work it out. :)
Posts: 17
Joined: Fri Nov 02, 2012 1:35 pm
by koalo » Wed May 01, 2013 12:57 pm
You should follow this
http://elinux.org/RPi_Kernel_Compilation

Use the long version and in section "Get the kernel source" use these commands:

Code: Select all
git init
git fetch git://github.com/koalo/linux.git rpi-3.8.y-asocdev:refs/remotes/origin/rpi-3.8.y-asocdev
git checkout rpi-3.8.y-asocdev


I have not tested it, but this should do it: For your application (raspberry pi in slave mode) you should change the file sound/soc/bcm2708/rpi-tda1541a.c search for SND_SOC_DAIFMT_CBS_CFS and change it to SND_SOC_DAIFMT_CBM_CFM

Then in the kernel config search for ALSA for SoC audio support, enable the support for BCM2708 and TDA1541A.

Compile the kernel, transfer it and use the following command to load the modules:

Code: Select all
sudo modprobe -a snd_soc_bcm2708 snd_soc_bcm2708_i2s bcm2708_dmaengine snd_soc_tda1541a snd_soc_rpi_tda1541a


I would be happy, to hear if this works.

Greetings,
Florian
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by Sniper435 » Wed May 01, 2013 1:02 pm
thank you so much :)
I'll get cracking on the build and let you know how things work out both with the build and with out breadboard prototype (actual hardware being soldered up atm)
Posts: 17
Joined: Fri Nov 02, 2012 1:35 pm
by marcelgl » Wed May 01, 2013 8:01 pm
Hi Florian,

Nice job! Will try it as well when I have time, but will be probably after 2 weeks :cry:
Posts: 11
Joined: Fri Mar 29, 2013 4:11 pm
by mhelin » Thu May 02, 2013 10:26 am
Great someone has took time for implementing the ASoC driver support. Is the RPi kernel version 3.8.x absolutely required? Got to upgrade the kernel first then. I haven't got time for anything but playing a little bit with user mode FIFO code which seemed to require SCHED_FIFO policy and took all CPU time available (any sleep between polling made cracking in sound). It might still be possible to use the user mode for the smallest latency.
Posts: 99
Joined: Wed Oct 17, 2012 7:18 pm
by koalo » Thu May 02, 2013 10:36 am
mhelin wrote:Great someone has took time for implementing the ASoC driver support. Is the RPi kernel version 3.8.x absolutely required? Got to upgrade the kernel first then.


3.8. is not absolutely required, it should also be possible to apply those patches to the 3.6. branch. However, I would like to switch to 3.10. sooner or later, because it will have some new features in the ASoC core. Why are you restricted to the 3.6. branch?
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by koalo » Thu May 02, 2013 11:06 am
koalo wrote:I have not tested it....


It should have been tested..... I forgot to register the device. I am sorry!
New version is pushed to github.
In order to see if the loading of the modules is working, you can run the following command. It should look like:

Code: Select all
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: sndrpitda1541a [snd_rpi_tda1541a], device 0: TDA1541A HiFi tda1541a-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by steveha » Fri May 03, 2013 3:38 pm
Dear all

I have been following this thread for a month. My intention is to set up raspberry PI to connect my NOS TDA1541A dac via I2S. I just followed koalo's instruction to compile the kernel and transfer the modules. Since I have no idea on slave I2S, therefore I didn't change sound/soc/bcm2708/rpi-tda1541a.c.

When performing modprobe, I come across 'bcm2708_dmaengine' is missing.
As a result, I just performed the modprobe w/o 'bcm2708_dmaengine' with success.

Now, I have the correct 'aplay -l' screen. However, ' card 1: sndrpitda1541a [snd_rpi_tda1541a], device 0: TDA1541A HiFi tda1541a-hifi-0 []' disappeared after poweroff.

What should I do next ? Thanks in advance to koalo.
Posts: 19
Joined: Fri May 03, 2013 3:15 pm
by Wavelength » Fri May 03, 2013 6:36 pm
Gang,

Sorry late to the party...

So basically to get I2S working on the GPIO port we need to get GPIO19 (PCM_FS) out. So what is needed to do that?

Thanks,
Gordon
Posts: 6
Joined: Fri May 03, 2013 6:14 pm
Location: Zinzinnati, Ohio 45227
by koalo » Fri May 03, 2013 9:31 pm
steveha wrote:My intention is to set up raspberry PI to connect my NOS TDA1541A dac via I2S.


I am happy to see more and more people working on this topic!

steveha wrote:When performing modprobe, I come across 'bcm2708_dmaengine' is missing.


Oh, yes, you find the corresponding setting under
Device Drivers -> DMA Engine Support -> BCM2708 DMA engine support. It will not function without it, although it might load.

steveha wrote:Now, I have the correct 'aplay -l' screen. However, ' card 1: sndrpitda1541a [snd_rpi_tda1541a], device 0: TDA1541A HiFi tda1541a-hifi-0 []' disappeared after poweroff.


That is normal - you have to repeat the modprobe after each reboot. Later this should be done via modules.conf, but that is another topic...

Greetings,
Florian
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by koalo » Sat May 04, 2013 6:40 am
Wavelength wrote:So basically to get I2S working on the GPIO port we need to get GPIO19 (PCM_FS) out. So what is needed to do that?


You buy a revision 2 board and solder a pin header at P5. Then you have PCM_FS on pin 4. (Maybe I misunderstood you question...)
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by DoctorH » Sat May 04, 2013 10:17 am
koalo,

It is my understanding that the default functionality ("ALT0") of the GPIO pins exposed on header P5 is not I2S audio, and these pins need to be configured to their "ALT2" function. Presumably this is done in drivers such as yours?
Posts: 9
Joined: Tue Apr 09, 2013 7:53 am
by DoctorH » Sat May 04, 2013 10:19 am
Wavelength, you should find this wiki useful.
Posts: 9
Joined: Tue Apr 09, 2013 7:53 am
by koalo » Sat May 04, 2013 10:38 am
DoctorH wrote:Presumably this is done in drivers such as yours?


Yes :-)
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by steveha » Sat May 04, 2013 2:34 pm
Hi Florian (koalo)

Well done. I would like to inform you that your drivers are really great. I have been suffering from
USB packet loss for a long period. :evil: Your I2S driver is just another story - smooth and noise free. :D

Currently, I am running mpd with P5 of raspberry PI (model B) connected to an I2S (LVDS) adapter. The I2S signals were carried by HDMI cable and transmitted to my TDA1541A dac. So far, I have no problems on streaming 44/16 and 96/24 materials. :shock:

BTW, is there any limitation on the brandwith (e.g. 176.4 ) ? I will perform some more testing and let you know the results.

Many Thanks
Steve
Posts: 19
Joined: Fri May 03, 2013 3:15 pm
by koalo » Sat May 04, 2013 3:06 pm
steveha wrote:Well done. I would like to inform you that your drivers are really great. I have been suffering from
USB packet loss for a long period. :evil: Your I2S driver is just another story - smooth and noise free. :D


Thank you :-D It is great, that someone - besides me - gets my driver running!

steveha wrote:So far, I have no problems on streaming 44/16 and 96/24 materials.


Maybe I have to disappoint you a little bit: The TDA1541A only supports 16 bit, the 24 bit material is rounded inside of ALSA. However, 96 kHz should be ok. I never tested that and since there is a little trick for multiples of 8000 kHz, it is great to hear that it seems to work!

steveha wrote:BTW, is there any limitation on the brandwith (e.g. 176.4 ) ? I will perform some more testing and let you know the results.


I don't know about any limitation. If you can find one, I would be nice to know! (What is this 176.4?)

Greetings,
Florian
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by steveha » Sat May 04, 2013 5:27 pm
Hi Florian

As your drivers are so good, they give me hopes for added values. I am thinking of other I2S capable dacs like Sabre ESS9018. The main difference between them is ESS9018 is running on 64fs bit clock I2S and TDA1541A only does 48fs. Also, ESS9018 can support higher sampling rates like 176.4 khz or 192 khz. Particular for 176.4 khz, I did aware there is a custom mpd to stream native DSD signals (i.e. not DoP) over I2S.

Regards
Steve
Posts: 19
Joined: Fri May 03, 2013 3:15 pm
by koalo » Sat May 04, 2013 6:20 pm
steveha wrote:The main difference between them is ESS9018 is running on 64fs bit clock I2S and TDA1541A only does 48fs.


In fact the driver currently runs at 40fs for 16 bit (that is the trick to get better clocks out of the Raspberry Pi). I don't know if that is a problem for some codecs, but let me know if it is. Furthermore, I think you should use an external clock source (or the one from a codec) if you are going to such high quality. I don't think that the Raspberry Pi has such a good clock (but I don't know...).

However, I just noticed that maybe the current driver will not run in slave mode as long as the external bit clock is not 40fs.... I will change that to.... 64fs or 48fs? Maybe it should be switchable....

steveha wrote:176.4 khz or 192 khz


I didn't even know that there are devices with such a high sampling rate :-) I will enable that inside the driver and maybe you have luck :-D
Posts: 121
Joined: Mon Feb 04, 2013 4:02 pm
by steveha » Sat May 04, 2013 6:48 pm
Latest results : There is no sound when using mplayer. It may be related to what you have mentioned.
I have already changed the default alsa to card 1 by changing /usr/share/alsa/alsa.conf with
defaults.ctl.card 1
defaults.pcm.card 1

I am using mplayer to listen intranet radio.

e.g. mplayer -ao alsa "http://58.64.197.165:8002/dbc1" ## DBC1

Greatings from Hong Kong :D
Posts: 19
Joined: Fri May 03, 2013 3:15 pm