STICKY: The I2S sound thread. [I2S works]

[audioplastic]

Following up form the last message, to get a bit more control, I compiled the latency test from alsa-lib and ran it and got the following output when using the using the dt-overlay in this gist.

Code: Select all

pi@raspberrypi:~/alsa_crap/alsa-lib-1.1.5/test$ sudo ./latency -P hw:0,0 -C hw:0,1 -r 44100 -m 128 -M 128 -p -s 1
Scheduler set to Round Robin with priority 99...
Playback device is hw:0,0
Capture device is hw:0,1
Parameters are 44100Hz, S16_LE, 2 channels, non-blocking mode
Poll mode: yes
Loop limit is 44100 frames, minimum latency = 128, maximum latency = 128
Unable to set hw params for capture: Device or resource busy
Unable to set sw parameters for playback stream: Device or resource busy

[audioplastic]

Switching to Paul Creaser's my_loader module (which actually gives meaningful input from the mics in half-duplex), gives the following output from the ALSA full-duplex latency utility . .

Code: Select all

alsa-lib-1.1.5/test$ sudo ./latency -P hw:0,0 -C hw:0,0 -r 44100 -m 128 -M 128 -p -s 1
Scheduler set to Round Robin with priority 99...
Playback device is hw:0,0
Capture device is hw:0,0
Parameters are 44100Hz, S16_LE, 2 channels, non-blocking mode
Poll mode: yes
Loop limit is 44100 frames, minimum latency = 128, maximum latency = 128
Unable to set hw params for capture: Device or resource busy
Unable to set sw parameters for playback stream: Device or resource busy

Similar deal. Any hints?

[audioplastic]

Got someone from Adafruit now saying that stereo full-duplex I2S is not an option at all on pi. Anyone know where this is documented. When I switch my code to single-in single out, I still get device busy messages.

[HiassofT]

Full duplex mode is supported by the hardware, only limitation is that playback and capture configuration (rate, format) must be the identical.

But there's a bug in the driver that prevents this from working when the RPi is configured as I2S clock master - hence the "busy" error from the latency check.

The error doesn't show up if RPi is configured as a clock slave or if input and output devices are opened separately (eg when using aplay | arecord) which explains why I'd missed that before.

I already know what's happening and why and I'm currently thinking about the best way to fix it.

I'll post an update when I have a working solution.

so long,

Hias

[audioplastic]

I already know what's happening and why and I'm currently thinking about the best way to fix it.

Sounds like progress, Hais! Thanks for giving this your attention. I eagerly await any further insights.

[targa]

I have a USB Sound Card and an I2S capture/play device (basically a mobile broadband network board, which has an I2S interface), one shall play the capture of another (use case: phone call on the USB device)....
How do I become clock slave? Leave out frame-master/bitclock-master?

How do I enable 8k sampling rate?

How do I enable MSB/Big Endian ?

Hi,
I was able to make the simple sound card accept S16_BE, so in theory everything should work. But it doesn't.
If I used arecord pipe into aplay, to see whether the mobile device can accept it's own stuff ( tried with and without conversion, raw, etc.) but I CAN recognize the sound I loop (I have alos tried to play out sound files). So I can recognize it, but it's not the real sound. Something 's wrong.

I attached a Saleae Logic Analyzer, I can see PCM incoming from the mobile device, (2MHz clock, 2 channels of which one is empty, I made a graph out of the i2s values which show something similar to a sine, which I used to testing).

But when I tried to loop this back to PCM OUT into the mobile device.... it doesn't amymore look like PCM, rather like PWM.... Ill post a screen shot.

Screenshot from 2018-01-12 14-36-13.png (35.96 KiB) Viewed 14832 times

[targa]

Sorry... obviously it's NOT PWM, but PCM with a totally different clock.
I connected the Pi's clock to different pins of the logic analyzer and noticed that the Pi ALSO generates a clock, which means he thinks he's master.... How can I disable that ? How can I make the Pi slave ?
I understood if I don't define the clocks in the overlay it's disabled = slave , not ?

I feel stupid

To

[targa]

Please, is there anyone out there who could give me a hand how to properly define master/slave in the HiassofT-Overlay ? I'm sure it's max 2 lines I need to add, but I'm now trying&error'ing and I would like to understand what I'm doing. I see it's probably better documented already in the "old way" using my_loader.c, but I'd prefer to stay on the new. I do have a I2s/PCM signal which comes with a clock I can't switch off, so I'd like the Pi to accept incoming clock.

Thanks a lot!!!

[HiassofT]

Please, is there anyone out there who could give me a hand how to properly define master/slave in the HiassofT-Overlay

Just use the bitclock-master and frame-master properties. See the bindings documentation for details and examples
https://github.com/raspberrypi/linux/bl ... e-card.txt

so long,

Hias

[HiassofT]

I already know what's happening and why and I'm currently thinking about the best way to fix it.

Sounds like progress, Hais! Thanks for giving this your attention. I eagerly await any further insights.

I've implemented a fix for the full-duplex issue, please give it a try and report back if it works: https://github.com/raspberrypi/linux/pull/2345

With that fix I could sucessfully use audacity in overdub mode and also run test/latency from alsa lib without issues:

Code: Select all

pi@raspbian:~/install/alsa-lib/alsa-lib-1.1.5/test $ sudo ./latency -P hw:0,0 -C hw:0,1 -r 96000 -m 128 -M 128 -p -s 1
Scheduler set to Round Robin with priority 99...
Playback device is hw:0,0
Capture device is hw:0,1
Parameters are 96000Hz, S16_LE, 2 channels, non-blocking mode
Poll mode: yes
Loop limit is 96000 frames, minimum latency = 128, maximum latency = 128
playback open OK
record open OK
trying bufsize 64
set bufsize OK
Hardware PCM card 0 'Dual' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 96000
  exact rate   : 96000 (96000/1)
  msbits       : 16
  buffer_size  : 128
  period_size  : 64
  period_time  : 666
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 64
  period_event : 0
  start_threshold  : 2147483647
  stop_threshold   : 128
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
Hardware PCM card 0 'Dual' device 1 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 96000
  exact rate   : 96000 (96000/1)
  msbits       : 16
  buffer_size  : 128
  period_size  : 64
  period_time  : 666
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 64
  period_event : 0
  start_threshold  : 2147483647
  stop_threshold   : 128
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
Trying latency 128 frames, 1333.333us, 1.333333ms (750.0000Hz)
Success
Playback:
*** frames = 96128 ***
  state       : RUNNING
  trigger_time: 1444.451666774
  tstamp      : 0.000000
  delay       : 72
  avail       : 56
  avail_max   : 120
Capture:
*** frames = 96000 ***
  state       : RUNNING
  trigger_time: 1444.451660785
  tstamp      : 0.000000
  delay       : 24
  avail       : 24
  avail_max   : 68
Maximum read: 64 frames
Maximum read latency: 666.667us, 0.666667ms (1500.0000Hz)
Playback time = 1444.451666, Record time = 1444.451660, diff = 6

so long,

Hias

[targa]

...
Just use the bitclock-master and frame-master properties. See the bindings documentation for details and examples
https://github.com/raspberrypi/linux/bl ... e-card.txt
...

Yes, I did read all this previously, but it didn't get clear to me WHERE exactly I can set enter those. I tried in fragments 0 and 1 and never got anywhere (Clock was always there).
So in the meantime I hardcodec CFM_CBM into the simple-utils module, along with negative bitclock trigger logic.

daifmt |= SND_SOC_DAIFMT_CBM_CFM
daifmt |= SND_SOC_DAIFMT_IB_IF
....and just to be sure I'm using I2s:
daifmt |= SND_SOC_DAIFMT_I2S

The debug output now gives
format : 1401
which seems ok to me

The signal I need to become compliant to is 256 bit wide, but it carries only 2 16 bit channels. I have the feeling, that the current code can handle max 2 channes 32bit-wide ? Is that correct? If I configure 256 -in hope the Pi would just pad the rest of the frame- bit the signal goes nuts. If I configure 128 bits it's halfway ok, seems i2s is waiting for the next frame.

So I can't control the actual format....Incoming I have 16 bit/8kHz signal in ch 2 out of 16 (256bit frame). Pi seems to halfway accept the frame clock, but the data chunks come too early, while the bitclock is somehow ignored.

[HiassofT]

@targa bitclock and frame master properties can be set in the dai link, eg like this:

Code: Select all

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    fragment@0 {
        target-path = "/";
        __overlay__ {
            dual_soundcard: dual-soundcard {
                compatible = "simple-audio-card";
                simple-audio-card,name = "Dual";

                status="okay";

                capture_link: simple-audio-card,dai-link@0 {
                    format = "i2s";
                    bitclock-master = <&r_codec_dai>;
                    frame-master = <&r_codec_dai>;

                    r_cpu_dai: cpu {
                        sound-dai = <&i2s>;

                        dai-tdm-slot-num = <2>;
                        dai-tdm-slot-width = <128>;
                    };

                    r_codec_dai: codec {
                        sound-dai = <&codec_in>;
                    };
                };

                playback_link: simple-audio-card,dai-link@1 {
                    format = "i2s";
                    bitclock-master = <&p_codec_dai>;
                    frame-master = <&p_codec_dai>;

                    p_cpu_dai: cpu {
                        sound-dai = <&i2s>;

                        dai-tdm-slot-num = <2>;
                        dai-tdm-slot-width = <128>;
                    };

                    p_codec_dai: codec {
                        sound-dai = <&codec_out>;
                    };
                };
            };
        };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {
            codec_out: spdif-transmitter {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dit";
                status = "okay";
            };
            codec_in: spdif-receiver {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dir";
                status = "okay";
            };
        };
    };

    fragment@2 {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };

};

If needed you can configure inverted frame or bitclocks signals there, too, just add "frame-inversion;" and/or "bitclock-inversion;".

The TDM setup in the DT above configures a slot width of 128 clocks, so a full stereo frame will have 256 clocks - I guess this is what you need.

The RPi can only drive up to 32 of each TDM slot, the remaining 96-112 bits will be padded up.

I'm not sure what exactly you mean with S16_BE, as that's a user space data format, I2S, DSP and left/right justified modes will always clock out the MSB of each data sample first.

so long,

Hias

[targa]

@targa bitclock and frame master properties can be set in the dai link, eg like this:

Thanks for the example, I was missing the part &r_codec_dai respective &codec_in which obviously means "take what comes in", right ?

If needed you can configure inverted frame or bitclocks signals there, too, just add "frame-inversion;" and/or "bitclock-inversion;".

Thanks a lot, that worked immediately. Sorry - I couldn't myself work out this path.

The TDM setup in the DT above configures a slot width of 128 clocks, so a full stereo frame will have 256 clocks - I guess this is what you need.

the above resembles pretty much what my experiments showed best results (I heard somewhat distorted, but recognizable the sound sample I intended to hear. Chaning to 125 instead of 128 would improve, so I wonder whether my incoming bitclock is maybe bad, or rather interfered, since I can see clock glitches on the analyzer as well).

The RPi can only drive up to 32 of each TDM slot, the remaining 96-112 bits will be padded up.

Thanks for confirmation, this was my understanding from the documentation and from what I saw on the analyzer, just I wasn't sure. Imagine I had a bad bit clock, in terms of "the clock is stepping too fast every now and then", how would the Pi react From my analyer output it looks like it's padding the empty bits and then starts a new channel data EVEN IF THE NEW FRAME CLOCK WASNT THERE YET. Is that something you can imagine ? That would actually explain why the sound sound better if I only configure 122....125 bits, then the chances are higher that the frame ist still in sync.

I'm not sure what exactly you mean with S16_BE, as that's a user space data format, I2S, DSP and left/right justified modes will always clock out the MSB of each data sample first.

now we come to an interesting piece of information. I knew in advance my incoming signal will be MSB, and from reading I understood that MSB means BE, since I want to output the sound towards a USB Sound device which accepts S16_LE, I was under the impression that I need also to actually convert BE in LE ? What I understand from you know is that I don't have to care about that ?

Can I do arecord -D hw:Dual | aplay -D hw:USB-device with no plug-conversion, et al ? Alsa is just taking the two stereo channels and putting them into target as it needs them ?

[HiassofT]

bcm2835 only synchronizes on the leading frame signal edge (i.e. in I2S mode when LR/framesync goes changes high to low) - the other edge is ignored. Therefore it's important that the bclk ratio / TDM slot width is setup correctly, the right channel sample is simply transmitted one slot width (i.e. 128 clocks with the above configuration) after frame start.

Do you have any docs for this thing? Is it really using I2S mode? Left justified mode looks similar to I2S on a scope, but the frame sync polarity is inverted and samples start 1 cycle earlier, compared to I2S mode. Using I2S instead of left justified mode will also lead to distortion, because the MSB will be lost then.

Bitclock polarity is important as well, it determines on which bitclock edge the input will be sampled and on which the output will change state. If setup wrong the input will be sampled on the same edge where the codec changes the data line which results in a pretty ugly mess.

Check these things carefully with your LA / scope to make sure the signal and setup is OK.

When you got the setup right you should be able to run aplay | arecord without any sample/format/... conversion - given that your USB DAC supports the samplerate / format you are using (not all devices can do 8kHz eg, some are even limited to 48kHz only).

There'll be one gotcha, though: as the sample clocks of your I2S codec and the USB soundcard aren't synchronized the clocks will quite certainly slowly drift away and you'll get an over- or underrun every now and then.

so long,

Hias

[targa]

Wow... update:
the other direction, in which the Pi receives the data works like a charm, outgoing I still see data chunks BEFORE the frame clock.
I can "feel" the sound, but not really hear it. I saw from some commercial DACs that they do modify the sysclock of the Pi (im on a PiZeroW). Is this something to look into? eg. the system clock (1GHz?) being to far away from a multiple integer of the bitclock, that it has troubles to properly follow the bitlock ? but 1 GHz seems to me to be enough oversampling distance....

bcm2835 only synchronizes on the leading frame signal edge (i.e. in I2S mode when LR/framesync goes changes high to low) - the other edge is ignored. Therefore it's important that the bclk ratio / TDM slot width is setup correctly, the right channel sample is simply transmitted one slot width (i.e. 128 clocks with the above configuration) after frame start.

does it actually "really" look at the bit clock as well, or does it just take frame width divided by "expected" amount of bits (frame width). This is actually my impression.

Do you have any docs for this thing? Is it really using I2S mode? Left justified mode looks similar to I2S on a scope, but the frame sync polarity is inverted and samples start 1 cycle earlier, compared to I2S mode.

From what I know, but that's for from what I believe, it's not exactly I2S, inverted frame sync BUT staring at 2nd cycle. This I can approve on the logic analyzer. What I don't understand is that the Pi sends data BEFORE the frame clock. I verified the bitclock polarity against what is incoming from the device.

Thanks for helping... Slowly I understand more about i2s and overlays.

[HiassofT]

In slave mode bcm2835 only uses the externally supplied clocks. The I2S block runs in an independent clock domain, either clocked by the PCM clock or externally via BCLK input - in slave mode the PCM clock isn't even set up.

In slave mode it's important that you setup the frame length parameters correctly. If you set them wrong, eg using 250 instead of 256 bclk cycles per frame, the result will be about what you seem to be seeing, bits transmitted before frame start. bcm2835 tries to sync to the frame clock but it will usually start transmitting the another frame after the configure frame length even if it didn't "see" another frame start.

So, have a closer look at the actual signals and if the bit and frame clocks don't match the specs dig further into that. You can find an illustration of the various formats eg on pages 46 and 47 of the wm8804 datasheet: https://d3uzseaevmutz1.cloudfront.net/p ... 4_v4.5.pdf

There are 2 other things to keep in mind: modes where the MSB follows immediately after the frame clock change (eg left justified or DSP mode B) don't work reliable with the bcm2835 in slave mode - in tests that lead to "channel swap/shift". The driver will warn about that.

The other thing is that some audio devices also provide or need a master clock (MCLK) signal, usually for their internal oversamplng filters. This signal is typically at 256-1024fs so it'll change multiple times per audio bit. You don't need that signal, only the bit clock and frame clock are relevant with bcm2835 audio interfacing.

so long,

Hias

[targa]

Thanks.

... bcm2835 tries to sync to the frame clock but it will usually start transmitting the another frame after the configure frame length even if it didn't "see" another frame start....

that actually explains what I see. I see on the analyzer that the incoming bit clock may be stepping too fast every now and then, is there a way to enforce to wait for the next frame clock (happy to patch the code for myself) because I currenlty can't influence the clock source.

I don't have the need for master clock.

[HiassofT]

that actually explains what I see. I see on the analyzer that the incoming bit clock may be stepping too fast every now and then, is there a way to enforce to wait for the next frame clock (happy to patch the code for myself) because I currenlty can't influence the clock source.

Page 121 of the "bcm2835 arm peripherals" doc mentions that it supports a legacy frame sync slave mode - maybe this could help a bit. To test this just uncomment this line in the driver:
https://github.com/raspberrypi/linux/bl ... i2s.c#L545

Code: Select all

mode |= BCM2835_I2S_FLEN(frame_length - 1);

That should set frame length to 0 and use the legacy mode. You may also have to uncomment the line below which sets frame sync length.

The doc mentions that legacy mode can corrupt the data out signal under some circumstances but isn't specific at all about which settings cause that...

It's still puzzling why your clock doesn't seem to be stable. Having a stable clock is the single, most crucial thing in all digital circuit stuff. You might need to hook up a scope to actually see what's going on there - glitches can usually be seen rather easily with a scope but not a LA, and modern DSOs (even cheap ones) often offer options to trigger on various glitch types.

so long,

Hias

[targa]

Thanks for the valuable help so far, I'll definitely take on that clock matter - later after i have sorted out my "intermediate" problem:

For "pin convenience" I wanted to re-route i2s pins to BCM18,27,24,23 which ought to be free. If you have a look at the header (Zero W) those pins lie close together in DIL-width, so that I can easily connect the level shifter I need to talk to the i2s-mobile-device which needs 1,8V. Now that I know about overlays a bit, I took the dts of the i2s-bcm28-31 overlay and changed 28 29 30 31 to 18 27 24 23 compiled it loaded it and.... NOTHING... using dtoverlay it wouldn't have any effect at all. When loaded during boot, I don't get any signal anywhere... ?!
I do have bt disabled to not interfere.
Is there something wrong with:

brcm,function = <6>; /* alt2 */

since I'm on the BCMs below 28 or does i2s always need alt2. I'm a bit confused here ?

the debug function says it's being loaded:

Code: Select all

pi@raspberrypi:~ $ dtc -I fs /proc/device-tree | grep i2s\ \{ -A 1
			i2s {
				brcm,pins = <0x12 0x13 0x14 0x15>;
pi@raspberrypi:~ $ sudo dtoverlay ./button-pin-overlay.dtbo
pi@raspberrypi:~ $ dtc -I fs /proc/device-tree | grep i2s\ \{ -A 1
			i2s {
				brcm,pins = <0x12 0x1b 0x18 0x17>;
pi@raspberrypi:~ $ 

Code: Select all

/*
 * Device tree overlay to move i2s to gpio 28 to 31 on CM
 */

/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709";

	fragment@0 {
		target = <&i2s_pins>;
		__overlay__ {
			brcm,pins = <18 27 24 23>;
			brcm,function = <6>; /* alt2 */
		};
	};
};

[HiassofT]

Rerouting the I2S GPIOs the way you'd like it doesn't work. bcm2835 doesn't support every function on every GPIO - actually only very limited options are available. A detailed table of possible configurations and ALT function numbers is available here: https://elinux.org/RPi_BCM2835_GPIOs

This means you can only use the standard configuration on RPi.

Since you mentioned the 1.8V levelshifter: check that it actually upshifts the 1.8V signal to 3.3V on the input pins (CLK, FS, DIN). FET levelshifters, which usually only downshift the signal, won't work reliably - 1.8V high level could be marginal for the 3.3V input.

Not sure if electrical interface specs of the RPi were ever published and what max V_IL and min V_IH actually are - if in doubt drive the input with 3.3V CMOS level.

so long,

Hias

[targa]

ok found it: not possible:
viewtopic.php?t=98318&start=25#p711623
Shouldn't there be some kind of error message ?

will need to do some re-soldering then....

Since you mentioned the 1.8V levelshifter: check that it actually upshifts the 1.8V signal to 3.3V on the input pins (CLK, FS, DIN). FET levelshifters, which usually only downshift the signal, won't work reliably -

I'm using TXB0108, they are bidirectional according to the specs.

[Rob Meades]

Hi I2S/ALSA experts.

I've got a very long way with connecting an I2S microphone (ICS43432) to my Pi but have failed at the very end in that I cannot get the capture volume boosted. The microphone is working correctly, it's just far too quiet and my attempt to boost the volume, using alsamixer and all the good advice here, gives me data bytes that are all zero. I've posted a thread requesting advice here, just cross-posting in the hope that one of you guys can help.

[targa]

Page 121 of the "bcm2835 arm peripherals" doc mentions that it supports a legacy frame sync slave mode - maybe this could help a bit. To test this just uncomment this line in the driver:
https://github.com/raspberrypi/linux/bl ... i2s.c#L545

Code: Select all

mode |= BCM2835_I2S_FLEN(frame_length - 1);

Before I was able to test this, I took another board and the problem just disappeared. Thanks for your hints, I learned a lot about i2s and Overlays. /T.

[idreyn]

I've implemented a fix for the full-duplex issue, please give it a try and report back if it works: https://github.com/raspberrypi/linux/pull/2345

Just wanted to drop a note to say thanks very much — I patched this in and it got my Pi doing simultaneous playback and recording with a CS4270!

[rotulet]

Hi,
I try to connect 4 modules DA-M1 from Audio-gd to my PI3 using I2S but I failed at finding a working driver.
I try to load :

• snd_soc_hifiberry_dac

• snd_soc_hifiberry_dacplus

• snd_soc_rpi_proto

• snd_soc_rpi_dac

• snd_soc_bcm2835_i2s

• snd_soc_iqaudio_dac

but 'aplay -l' give me only the default sound cards:

Code: Select all

**** 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 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Do you have any ideas?

Thanks