STICKY: The I2S sound thread. [I2S works]

[dariush]

Or you could solder a wire to one of the PCM/I2S pins going to the 'revision' resistors.

That's what I meant with modding the Pi.

cheers
Dariush

[nikkov]

-> PCM_MCLK: is a fixed clock at 3.072Mhz (really fixed?)

I have to ask about that one. I am not familiar with it.

Hi Gert,

Can you explain any info about what's PCM_MCLK? Can I use an external master clock for PCM_MCLK?

[error404]

To hopefully clear up what appears to be some confusion, there are 4 signals typical in unidirectional I2S:

MCLK - This is the DAC master clock, depending on the DAC you choose the requirements may be different. Systems using I2S to transfer digital audio data don't usually require it (e.g. to convert to SPDIF). It's typically an oversampled clock at 256 x Fs (ie. 11.289.600Hz for 44.1KHz). It's typically the clock source for all other clocks in the system. According to the datasheet, this is an input in the Pi implementation, and can be used to generate the other clocks when the Pi is a clock master. It shouldn't be required if the Pi is a slave.

LRCLK - This serves two purposes. It synchronizes the samples (ie. times them vs. the bit clock), signals which channel is being sent (usually LEFT when low), and clocks the new samples into the DAC. It will have a frequency equal to Fs.

SCLK - This is the bit clock, an edge marks a bit in the incoming serial stream. This clock depends on the sample bit depth; for I2S which is usually either 16b or 32b (padded if necessary). It will be at Fs * 2 * bits.

DIN - Data appears here. MSB first.

[nikkov]

MCLK - This is the DAC master clock, depending on the DAC you choose the requirements may be different. Systems using I2S to transfer digital audio data don't usually require it (e.g. to convert to SPDIF). It's typically an oversampled clock at 256 x Fs (ie. 11.289.600Hz for 44.1KHz). It's typically the clock source for all other clocks in the system.

Yes, that's right
I want to use external master clock 256 x Fs and BCLK, LRCLK in master mode

According to the datasheet, this is an input in the Pi implementation, and can be used to generate the other clocks when the Pi is a clock master. It shouldn't be required if the Pi is a slave.

I can't find any info about source for PCM_MCLK in datasheet by Broadcom

[error404]

The section 'typical timing' (p120) gives a brief mention:

In clock master mode (CLKM=0), the PCM_CLK is an output and is driven from the
PCM_MCLK clock input.
In clock slave mode (CLKM=1), the PCM_CLK is an input, supplied by some external clock
source.

Actually upon re-reading this section, it sounds to me like this is likely to be an internal clock source coming from the clock generation blocks, which are not defined in this datasheet. Definitely sounds like it's the serial bit clock though, not the DAC master clock, so I would assume that you'll need to generate the bit clock from MCLK yourself and inject it at PCM_CLK with the Pi configured as a clock slave. In a normal application I guess you could run the master clock directly into the SoC's clock architecture and generate all the I2S clocks internally (we don't have the docs to be able to do this, even if we had the hardware flexibility), but I think in this case you'll have to generate at least the bit clock yourself. Reads like the Pi can divide that down automatically by your selected bit depth to give you LRCLK though, that's handy.

[ceteras]

@error404: the DAC master clock is not actually part of the official I2S specifications.
I2S is three wires. Source here.
You're talking about the system clock required by some dacs to operate, that is not supposed to be supplied by the PI, nor is it part of the I2S bus.
For example "The system clock for PCM1717 must be either 256fS or 384fS, where fS is the audio sampling frequency (typically 32kHz, 44.1kHz, or 48kHz). The system clock is used to operate the digital filter and the modulator.", from the PCM1717 datasheet.

I couldn't find the PCM_MCLK either, but I plan to use the PCM_CLK as an input, and I'll find a way to generate the clock in hardware, hopefully more precise than I could get from dividing some unknown internal clock.
So perhaps this would be the best approach, have a master clock generated from a quartz oscillator, divide it by 8 and you have a very stable PCM_CLK to feed both the PI and the dac.

[nikkov]

Actually upon re-reading this section, it sounds to me like this is likely to be an internal clock source coming from the clock generation blocks, which are not defined in this datasheet.

So I'm here and ask about it

Definitely sounds like it's the serial bit clock though, not the DAC master clock, so I would assume that you'll need to generate the bit clock from MCLK yourself and inject it at PCM_CLK with the Pi configured as a clock slave.

BCLK is usually a derivative of MCLK (as I know about I2S module in other microcontrollers)
BCLK in slave mode is reserve variant for me.

[DogEars]

I'm trying to get this working correctly with 44.1/16bit stereo.

What do I put for FLEN & FSLEN in the MODE_A register?
Do I need a Frame Length or 32bits and a Frame Sync Length of 16bits; this is what i've got:

Code: Select all

*(i2s+2) = 31<<10 | 16;  // bits 19:10 FLEN , 9:0 FSLEN 16

What do I use for Channel 1 & Channel 2 Postition & Width
Do I need the CH1 to start at bit 31 and CH2 to start at bit 15?
Am I understanding the docs correctly, does setting the CH1/2WID to 8 give me 16bit width?

Code: Select all

*(i2s+4) =  1<<30  | 1<<14 //enable channel 1 & 2
          | 8<<16  | 8     //       channel 1 & 2 width
          | 31<<20 | 15<4; //  ch1 pos: 31, ch2 pos = bit 15

Any input gratefully received,
Ears.

[ceteras]

Hi Ears,
I have the same numbers for FLEN & FSLEN.
For CH1POS and CH2POS, I would go for 0 and 16, that is CH1 starts with the first clock in the frame, and CH2 with the 17th. It's not the bit number, but chronological order.
"Channel 1 Position
This sets the bit clock at which the first bit (MS bit) of channel 1 data occurs in the frame.
0 indicates the first clock of frame."
CH1/2WID = 8 gives 16bit width if CH1/2WEX = 0 which in your case it is.

[Chii]

Talking of a hardware master clock would a pink fish media flea with a tent labs clock do the job. And is so what's the input pin for the pi?

[Gert van Loo]

....what's the input pin for the pi?

The PCM/I2S clock pin changes direction if you put the module interface into 'use external clock' mode.

[DogEars]

....what's the input pin for the pi?

The PCM/I2S clock pin changes direction if you put the module interface into 'use external clock' mode.

Hi Gert,
This is the bit clock, wouldn't changing this to slave mode require a clock of, say 1.4112Mhz being supplied not the Master clock of 11.2896Mhz. That's the clock that would be the source all clocks in the system the DAC and the RPi.

Alternatively you mention in post 4 of this thread the PCM clock registers at 0x7E101098 and more importantly the source (SRC) bits 3:0; could we supply a master clock there and divide down for the bit clock and use the input of that source to drive the DAC? lookin at the docuemnted clocks there are a few other sources, are any of those connected to pins we can get at?

Assuming the sources for the PCM clock are the same as the general purpose clocks?
0 = GND
1 = oscillator
2 = testdebug0
3 = testdebug1
4 = PLLA per
5 = PLLC per
6 = PLLD per
7 = HDMI auxiliary
8-15 = GND

[Gert van Loo]

Using anything but the external oscillator is difficult as the PLLs are shared between various blocks. I have no idea what the PLL frequencies are set to. That is all done in the SW. You can not change a PLL frequency without knowing what it is used for. Normally the clock distribution is done by the GPU which has some very clever algorithms to decide how to generate the different clocks from the various PLL's. That is more Dom's domain.
The X-tal is the cleanest signal with the least amount of noise. I am no an audio expert but I have always been told to use the cleanest clock.

I have no idea what you mean with "This is the bit clock, wouldn't changing this to slave mode require a clock of, say 1.4112Mhz being supplied not the Master clock of 11.2896Mhz. That's the clock that would be the source all clocks in the system the DAC and the RPi."
The PCM module runs of a bit clock. You can select that clock to come from the GPU, in which case the GPIO clock pin is an output.
Or you can select an external clock, which case the GPIO clock pin becomes an input and YOU have to connect an external clock signal to drive that input.

[nertia]

Sorry to butt in to what is obviously quite a technical discussion with what might be an ignorant question, but I was wondering if the following is possible:
I would like to know if it would be possible (now or in the future) to connect the AMB Labs y2 DAC directly to the I2S bus of the Raspberry PI.

http://www.amb.org/audio/gamma2/instructions.html

The DIY product is part of an integrated modular DAC that is usually mated to the y1 to provide it's input, however the build instructions state that it can be used in "standalone" mode to provide an upgrade to CD players or anything capable of outputting I2S. The connections it requires are:

Pin 1: Ground
Pin 2: MCLK
Pin 3: LRCLK
Pin 4: BCLK
Pin 5: DATA

I know that some wires would need to be soldered to specific resistors to access the bus and that there are all sorts of technical issues (that I don't understand) being discussed so my questions are:

1. Can the PI output the required data to feed the y2 (I haven't seen any reference to LRCLK)?
2. Is there any point in doing this or would it be easier to create an SPDIF signal from the PI's output.
3. What are the issues that would need to be overcome in terms of drivers e.g. ALSA to make this work.

My (possibly naive) reasoning for wanting this is to build a good quality, wireless enabled music server using an existing high quality DAC in a physically small package. If the PI could drive the I2S
of the y2, both could be powered from the same 5V supply and considerable cost savings could be made over building a complete y1+y2 standalone DAC.

Please let me know if the dream is dead (or stupid).

[DogEars]

We've got the I2s interface woring with a Twisted Pair Buffalo DAC, as it doesn't require the master clock (MCLK) input. We're hoping to get it working with a cheaper DAC, hopefully with the Pi supplying the MCLK.

The LRCLK translates to the PCM_FS available via one of the tiny resistors not fitted to the Pi. see the attached image.

[nertia]

I would be interested in the some more detail on how you got the Buffalo DAC working, have you got a URL? I am not sure if the y2 requires MCLK from the pi either, although I will try to verify this.

From http://www.amb.org/audio/gamma2/
"An optional asynchronous sample rate converter (ASRC) chip (Texas Instruments/Burr-Brown SRC4192 or Analog Devices AD1896) up-samples all input digital streams to 24-bit 96KHz. The ASRC and DAC are both fed with an I²S master clock generated by an onboard ultra-low jitter CMOS oscillator. Together with careful circuit board layout, the result is an extraordinarily low overall jitter."

This DAC kit has a good reputation among headphone enthusiasts and, according to my Mouser BOM, can be built for ~£60. I don't really understand the underlying technologies, but from what I understand an I2s connection over short distances can have some sonic advantages over SPDIF.

[Thomas S]

I2S is the industri standard for audio transfer, and would make the Pi succesful as an streaming device for audio.

It is therefore nice that I2S can be taken from the board, eventhough it would be nice if it was available directly at the P1 pinheaders.

Has anyone tried with higher resolution music ? 24bit 192KHz seems to be more and more popular. Any problem in streaming that ?

[McDaisy]

We've got the I2s interface woring with a Twisted Pair Buffalo DAC, as it doesn't require the master clock (MCLK) input. We're hoping to get it working with a cheaper DAC, hopefully with the Pi supplying the MCLK.

The LRCLK translates to the PCM_FS available via one of the tiny resistors not fitted to the Pi. see the attached image.

Hi!
Ive been following this thread for a while and observing everyones success with this. Im more a hardware guy than software. My skills in linux/programming is quite limited.

Im planning integrating my RPi into my dac and feed is with i2s. I really would appriciate if you could explain (maybe step by step) how you got you buffalo dac working. That would really help me a long way on the road =)

Thanks!

[kachel]

We've got the I2s interface woring with a Twisted Pair Buffalo DAC, as it doesn't require the master clock (MCLK) input. We're hoping to get it working with a cheaper DAC, hopefully with the Pi supplying the MCLK.

The LRCLK translates to the PCM_FS available via one of the tiny resistors not fitted to the Pi. see the attached image.

Hi DogEars, could you tell me what you think of the quality of the signal? My plan is to hook it up to a buffalo as well and I am wondering if this is the best way to do that. Thanks!

[fish]

I have been working with Dog Ears on the DAC hardware, with the help of people on this forum he has completed code that enables the I2S bus and passes 44.1/16 audio, we have tested this with 3rd party DAC's PCB's and it appears to work well although the operation does not benefit from a GUI yet.

He is currently busy trying to enable a seperate Masterclock output at 256 x the bitclock (bitlclock is a part of the I2S buss) Masterclock + I2S are the signals some/most DAC IC's need to function,.

Thomas S,
there are also ideas of using the PI's SPI or I2C to dynamically control the DAC IC registers to allow use at 192/24 and 96/24 audio with the correct DAC filters etc.

Kachel,
The Pi's output signals look very clean, although I have not measured jitter as of yet I blieve it will be negligible.

Nertia,

1. Can the PI output the required data to feed the y2 (I haven't seen any reference to LRCLK)?
Yes it can. LRCLK is a part of the I2S bus.
2. Is there any point in doing this or would it be easier to create an SPDIF signal from the PI's output.
Good question, I believe you will get better audio and a more integrated solution by using i2s over SPDIF.
3. What are the issues that would need to be overcome in terms of drivers e.g. ALSA to make this work.
"Drivers" is were Dog ears is putting in the work. there is a lot experimentation required as the Broadcom datasheet is a little hard to follow in some areas.

[valtonia]

Hi Guys,

I normally hang out in the bare metal section but I noticed this post and thought you might be able to help me.

I'm trying to get the PCM block working, trying a simple test (in polling mode) to just get some noise out of the Rpi and it's sort of half working, but behaving in strange way.

First, the sync bit in the cs_a register - the doc says write 1 to this and 2 clocks later it will read back as 1. Doesn't seem to be working for me. I write 1, the value reads back as 0 forever.

Second, by following the bcm2835 doc I'm trying the following sequence:

enable pcm block:
set cs_a.en = 1

clear any errors/reset fifo's:
set cs_a.txclr = 1
set cs_a.txerr = 1
set cs_a.rxclr = 1
set cs_a.rxerr = 1

set up the channels:
txc_a.ch1en = 1
txc_a.ch1pos = 0
txc_a.ch1wid = 8
txc_a.ch1wex = 0
(ch2 disabled for this test)

set up the mode: (this is the part I've probably gotten wrong)
mode_a.clk_dis = 0
mode_a.pdmn = 0
mode_a.pdme = 0
mode_a.frxp = 0
mode_a.ftxp = 0
mode_a.clkm = 0
mode_a.clki = 0
mode_a.fsm = 0
mode_a.fsi = 0
mode_a.flen = 1
mode_a.fslen = 1

Finally, I write to fifo_a until cs_a.txd = 0 and then I write cs_a.txon = 1. (I've also tried setting cs_a.stby = 1 but no change).

At this point I expect the fifo to start emptying the the txw, txe and, txd bits to change, but nothing happens at all.

I know it's hard to diagnose from this description without seeing my code or anything, but can anyone think of anything obvious I'm missing?

Cheers,
A.

[N2TOH]

not to arm chair engineer things here, but you folks might want to take a look at this site with S/PDIF and TOSLINK interfaces. http://www.epanorama.net/documents/audio/spdif.html from what I gather it should be very cheap to add on a set of SPDIF inputs and outputs for the Pi.

[DogEars]

I know it's hard to diagnose from this description without seeing my code or anything, but can anyone think of anything obvious I'm missing?

Cheers,
A.

Did you get this working?

G.

[jojopi]

see the attached image.

The coloured boxes for GPIO28 are clearly misplaced in that image. It should be:

gpio2831.png (59.47 KiB) Viewed 35225 times

[McDaisy]

Could someone please just tell me if this is correct?
Higher resolution here http://dl.dropbox.com/u/99908900/Raspberry%20PI.jpg

Thanks!