Building an open embedded audio applicance.

[TBM]

Looking good!

Just want to make a point that I am also NOT interested in making this cape "low end" and save a few bucks. PLEASE make it "high end" with the best clocks, power, isolation,... for interfacing to the Buffalo

IMO after this is done, then an other cape with features like included "low end" DAC, cheaper clocks, no reclocking etc can be developed, IF time and interest is there...

Please be aware of the "scope creep monster"...

Cheers

 

[miero]

Roll off issues with I2S

I've measured HUGE difference of ES9018 filter roll off when using I2S.

Any idea? Bad settings?

White noise signal on SPDIF generated by onboard sound card and ARTA.
White noise signal on I2S generated by following command on BBB:

$ dd if=/dev/urandom | aplay -r 48000 -c 1 -f S24_3LE -

For 16bit it looks similar, but for 32bit the roll off is even more strange and roll-of is moved to 48kHz instead of 24kHz.

EDIT: first two images are for SPDIF input and the other two (with much noise) are for I2S input.

 

[DQ828]

Looking good!

Just want to make a point that I am also NOT interested in making this cape "low end" and save a few bucks.
Cheers

Is it possible to have both? your cake & eat it to

 

[peufeu]

I've measured HUGE difference of ES9018 filter roll off when using I2S.

Any idea? Bad settings?

Check frequency of BCLK, WCLK of your I2S, using oscilloscope. Check ALSA settings. It may perform some oversampling or other processing.

 

[Russ White]

For 16bit it looks similar, but for 32bit the roll off is even more strange and roll-of is moved to 48kHz instead of 24kHz.

It looks like either bit clock and/or the word clock are double the expected rate.

 

[miero]

OK, I'll check the I2S output with logic analyzer soon.

 

[peufeu]

If you use a scope and proper probing you can also check for ugly looking clock signals, which can cause all kinds of trouble (ringing -> double clocking), etc

 

[clivem]

Default settings work on a pi so should be ok for BBB. They also work well on a wandboard which is what we are using for CSOS.

Pi doesn't have the horse-power (CPU bound) to resample on-the-fly to >96k. Not sure how the BBB compares, hardware wise. ISTR, upsample was fine up to 192k with the original BB I have. Not used that for a couple of months, though. (And not sure if the BBB uses the same processor as the BB.)

I'm building the latest CSOS F20 kernel with a bunch of patches for the BBB. Not sure this is going to happen anytime soon, but I'll add miero's BBB I2S patches to the next build, assuming they apply to the latest mainline. Then, maybe Chris can try my CSOS F20 test image on the BBB.

Miero, your code, are you using recent kernels and device tree for initialisation?

 

[miero]

Miero, your code, are you using recent kernels and device tree for initialisation?

Yes, it is developed for kernel 3.8.13 and it uses device tree for initialization.

I've not tried it with the 3.12.x yet.

 

[clsidxxl]

I have this issue with alot of attention,but if I understand I2S output Raspi and BeagleBone Black are not bitperfect is the current state?

 

[miero]

Measured bare I2S output from BBB, no DAC connected.

Signal changes on falling clock side.
Data is delayed 1 by LRCLK.
MSB is on the left, LSB on the right.
Playing 16/24 bit keeps data aligned on the left side.
Analog channels of BCLK, LRCLK and DATA seems well (BCLK is not shown, but well aligned with LRCLK/DATA).

Seems OK to me.

One thing that might be incorrect is Left-Right side.

 

[Russ White]

bck timing looks like it might possibly be 33 pulses... or I could just be counting badly.

 

[Russ White]

Word clock should also change of the falling edge of the bitclock.

You probably are doing it correctly, but Data actually needs to be wrapped when delayed one bitclock cycle. For example: The LSB of the Left channel will be clocked in as the first bit after wordclock transition to right channel directly followed by the MSB of the right channel.

 

[Russ White]

It is really better to look at it as the word clock transition preceding the next data word (MSB) by one bit clock cycle.

 

[miero]

Only single channel was playing, other one was muted. So it should be OK. And yes, there are 32 pulses...

 

[Russ White]

There should be something clearly different between the 16/24 and 32bit playback. Can you show them all together?

 

[miero]

Only difference is that 32bit playback can use all bits in the word.

Captures with both MSB and LSB for 16, 24 and 32 bit playback:

 

[Russ White]

just out of curiosity try always making the LSB 0 and see if that brings the filter back into the right fs range.

 

[miero]

Does it happen with other I2S transports? I have just BBB at home, so I can't test this.

Also, I'm using 5cm wires between BBB and B3 without any termination, so this might do no good too.

I can try to do more test tomorrow...

 

[clivem]

Yes, it is developed for kernel 3.8.13 and it uses device tree for initialization.

I've not tried it with the 3.12.x yet.

I think you'll need at least a 3.13.x to boot BBB with a mainline, non-patched kernel. (Not sure on that, but ISTR reading it somewhere.)

OK. I just had a quick 5 minute look, with a view to integrating your code into mainline kernel...... I see use of device tree overlays and cape manager...... That will be a problem with mainline I think, the lack of cape manager functionality.

Modules compile OK with 3.13.6. Suspect it might work OK with a static (boot time only) dts file. Will look again at some point in the future. I'm keen not to go down the path of vendor supplied kernels. Have had enough of that. Don't ask!