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
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
Last edited:
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.
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.
Attachments
Last edited:
Check frequency of BCLK, WCLK of your I2S, using oscilloscope. Check ALSA settings. It may perform some oversampling or other processing.
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
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?
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 have this issue with alot of attention,but if I understand I2S output Raspi and BeagleBone Black are not bitperfect is the current state?
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.
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.
Attachments
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.
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.
It is really better to look at it as the word clock transition preceding the next data word (MSB) by one bit clock cycle.
Only single channel was playing, other one was muted. So it should be OK. And yes, there are 32 pulses... 😀
There should be something clearly different between the 16/24 and 32bit playback. Can you show them all together?
just out of curiosity try always making the LSB 0 and see if that brings the filter back into the right fs range.
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...
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...
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! 😉