Enable 352k8 and 384k sample rates for I2S connected boards/HATs that support those rates

[clivem]

This is another RFC, please do not pull!

I have tested original HiFiBerry DAC (PCM5102) on a PiB and HiFiBerry DAC+ (PCM5122 slave) on a Pi2B @ 352k8 and 384k.
I have tested first gen IQAudio DAC on a PiB, IQAudio DAC+ on a Pi3B, IQAudio Zero DAC on a PIZero @ 352k8/384k.

What I cannot test right now is HB DAC+ Pro (BCLK master / LRCK master) audio playback at 352k8 and 384k. (I lent my DAC+Pro to someone who doesn't appear to comprehend there is a difference between "loan" and "gift"!) @bonezuk @hifiberry don't know if you need to modify your driver for master mode (MCLK divider for BCLK?????), but it might be worth your while testing now rather than later. As I already said, your slave mode, works "out of the box" with this patch set.

Their is still chatter going on in DIY circles about over/upsampling (externally) to 8x on the TI PCM5 series, to bypass the TI OSF. (Can't switch it off, but by up/oversampling to 8x data rates in software and sending to the DAC, internal OS filter is bypass or 1x mode.) Me thinks that if 384k support isn't added via downstream first, at some point it will trickle down from upstream.......

[clivem]

I'll re-post the image (I generated when testing upstream i2s/dma backport code) showing the clock frequencies generated from PLLD parent, for 352k8@32/64 bit frame size and 384k@32/64 bit frame size.

Anyway, as I already said, PCM5xxx slave is fine. It's the HB DAC+Pro board that needs testing in master mode @352k8/384k.

[hifiberry]

@clivem Send me a message with your email that we can send you a new DAC+ Pro. We test this. In general it should be possible to get this running even if I'm not sure why anybody would really need 384kHz sampling rate. But that's another question.

[clivem]

Send me a message with your email that we can send you a new DAC+ Pro.

Will do.

In general it should be possible to get this running even if I'm not sure why anybody would really need 384kHz sampling rate.

@hifiberry Well, for the majority of your customers it is not necessary. We both know that! ;)
But wanting to oversample in software and bypass the TI hardware FIR is a good enough reason as far as I am concerned, not that I'm buying into any of the usual high-res BS.

[HiassofT]

ALSA already supports arbitrary samplerates via SNDRV_PCM_RATE_KNOT. No need to add SNDRV_PCM_RATE_384000 etc to the core ALSA headers, these are just shortcuts for frequently used rates.

[clivem]

ALSA already supports arbitrary samplerates via SNDRV_PCM_RATE_KNOT.

Yes, I'm aware of that. The problem with using KNOT is the "arbitrary", rather than actual "predefined" rates the hardware can support. ;)

[HiassofT]

Non-constrained rates would be SNDRV_PCM_RATE_CONTINUOUS - I think we could use that in bcm2835-i2s (would need testing though).

When using KNOT you call snd_pcm_hw_constraint_list in .startup and pass it an array of available rates. ALSA intersects all the parameters&constraints of DAIs and CODECs and only allows configurations allowed by the whole chain.

So if you have CONTINUOUS (or a constraint including 384000) in I2S and a constraint including 384000 in the codec you'll be able to use 384kHz.

[clivem]

When using KNOT you call snd_pcm_hw_constraint_list in .startup and pass it an array of available rates. ALSA intersects all the parameters&constraints of DAIs and CODECs and only allows configurations allowed by the whole chain.

Yes, I know how it works. But that means adding methods and more lines of code, (to drivers that don't already use constraints), than adding a couple of defines to ALSA headers and changing SNDRV_PCM_RATE_8000_192000 to SNDRV_PCM_RATE_8000_384000. Not saying that it can't be done the way you suggest, it's the way I was doing it for over a year.....

[HiassofT]

If you want SNDRV_PCM_RATE_384000 included it's best to post on the alsa-devel list and convince the ALSA people to add it.

There was a request for that a few months ago but it wasn't accepted, looks like the submitter didn't present convincing arguments:
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103497.html

Having such patches only in the downstream RPi kernel doesn't make much sense and only complicates things when there are upstream changes.

[clivem]

LOL.....

So without needing to convince upstream ALSA, something like this for bcm2835-i2s and the codecs actually nailing down specific supported rates by constraint rather than ALSA define.

@@ -626,7 +626,9 @@
.playback = {
.channels_min = 2,
.channels_max = 2,

•           .rates =        SNDRV_PCM_RATE_8000_192000,
  

•           .rates =        SNDRV_PCM_RATE_CONTINUOUS,
  

•           .rate_min =     8000,
  

•           .rate_max =     384000,
            .formats =      SNDRV_PCM_FMTBIT_S16_LE
                            | SNDRV_PCM_FMTBIT_S24_LE
                            | SNDRV_PCM_FMTBIT_S32_LE
  

[clivem]

NB: The "Add rate defines for 352k8 and 384k" is not required by the other patches. (All driver code has been changed to use CONTINUOUS/KNOT and constrants lists for 352k8/384k and tested to be working as expected.) It's just been added back as a "placeholder" so I don't forget to submit it to ALSA mailing list.

[clivem]

@pelwell OK, I'll submit patches 1 (384k: bcm2835-i2s: Support 384k sample rate), 2 (384k: pcm512x: Add 352k8 sample rate support), and 3 (384k: pcm5102a: Support 352k8 and 384k sample rates) upstream. Patch 4 (384k: pcm5102a: Add dt mechanism to limit rate support, which has been split from the original patch 3, to limit pcm5102a sample rate support back to 192k for hifiberry_dac support of es9023 and have to specify 384k dt param to enable 384k MAX support), is going to have to be a downstream patch, I think. I don't have a hope in hell of selling that to upstream, by explaining it's needed by a downstream machine driver, which is using the pcm5102a codec driver for es9023 hardware..... ;) Patch 5, (384k: hifiberry_dacplus: Support 352k8 sample rate), to hifiberry_dacplus machine driver, that's for downstream.

[clivem]

@pelwell Patches in the right order now. Do you agree with what I proposed?

[clivem]

@pelwell I just fired-off those first 3 patches to the relevant mailing lists.

[clivem]

I have neither the time or the will, to play the upstream game. I have tried. I will continue maintaining the patch sets outside of the RPi kernel tree. It is a shame that only a limited number of people will benefit from functionality that is possible with many of the 3rd party hardware DAC boards that are being made available for the Pi, because it is not made available by the "official" RPi kernel sources.

[shawaj]

@clivem where are your patch sets located? Do you have a branch specifically for them?

[clivem]

The 384k on its own, https://github.com/DigitalDreamtimeLtd/linux/commits/rpi-4.4.y-384k

The audio distributions and a'phool forum guys building their own kernels are running what is referred to as the complete simple audio patchset.... which includes the clockmgr/i2s backport to rpi-4.4.y, es9023, 384k, regulator, simple-framework (for the 40/80 and 50/100 bclk_ratio via simple card).... https://github.com/DigitalDreamtimeLtd/linux/commits/rpi-4.4.y-simple

[clivem]

@shawaj There is also a private tree, which I cannot make public, which on top of "simple" contains the "other" audio stuff.... The driver I'm not allowed to release as an Open Source driver, an AK4xxx driver, and also bundled into it, the Wolfson/Cirrus card support, which still isn't downstream. I don't think you'd have any interest or need for this anyway, if you are using TI PCM5xxx for the DAC's and WM8804 for Digi....

[kittybuttontin]

I have a HiFiBerry DAC+Pro but I can't get 384k to work in master mode (I only get 352k). I do get 384k in slave mode.

I was under the impression from some of the posts above that it should work in master mode?

[clivem]

HiFiBerry DAC+ Pro works @ 352k8 and 384k, in both master and slave modes with this patchset applied.

[kittybuttontin]

Thanks. I am using this patchset, but for some reason 384k is not working in master mode:

cat /proc/asound/card0/pcm0p/sub0/hw_params

access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 2048
buffer_size: 65536

[clivem]

All that shows me is that your audio playback software is actually opening the device at 352k8. Show me the error from your playback software when it tries to open the device at 384k, please? Show me the output from alsacap where it will display the min and max supported sample rates. eg.

$ alsacap
Card 1, ID `sndrpihifiberry', name `snd_rpi_hifiberry_dacplus'
  Device 0, ID `HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0', name `', 1 subdevices (1 available)
    2 channels, sampling rate 8000..384000 Hz
    Sample formats: S16_LE, S24_LE, S32_LE
      Subdevice 0, name `subdevice #0'

This log shows the device initially opened at 44k1, then closed and re-opened at 384k.
384k.txt

[clivem]

Also, for the benefit of anyone else trying to enable 384k support on the TI chipset boards, make sure you are using the latest version of the 384k patch set from rpi-4.4.y-384k which I try to keep current with Foundation rpi-4.4.y.

[kittybuttontin]

Master mode output of alsacap:

Card 0, ID sndrpihifiberry', namesnd_rpi_hifiberry_dacplus'
Device 0, ID HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0', name', 1 subdevices (1 available)
2 channels, sampling rate 8000..352800 Hz
Sample formats: S16_LE, S24_LE, S32_LE
Subdevice 0, name `subdevice #0'

Master mode output of mpd:

Sep 29 16:21 : decoder_thread: probing plugin flac
Sep 29 16:21 : decoder: audio_format=192000:24:2, seekable=true
Sep 29 16:21 : decoder: converting to 384000:32:2
Sep 29 16:21 : alsa_output: opened hw:0,0 type=HW
Sep 29 16:21 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Sep 29 16:21 : alsa_output: buffer: size=64..65536 time=181..185760
Sep 29 16:21 : alsa_output: period: size=32..32768 time=90..92880
Sep 29 16:21 : alsa_output: buffer_size=65536 period_size=2048
Sep 29 16:21 : output: opened plugin=alsa name="Software Volume" audio_format=352800:32:2
Sep 29 16:21 : output: converting from 384000:32:2

Slave mode output of alsacap:

Card 0, ID sndrpihifiberry', namesnd_rpi_hifiberry_dacplus'
Device 0, ID HiFiBerry DAC+ HiFi pcm512x-hifi-0', name', 1 subdevices (1 available)
2 channels, sampling rate 8000..384000 Hz
Sample formats: S16_LE, S24_LE, S32_LE
Subdevice 0, name `subdevice #0'

[clivem]

I'd suggest you read the commit log for DigitalDreamtimeLtd@3f7f2bb and make sure you have actually applied it along with other patches. ;)

You need to apply all 6 patches (the last 6 patches) from the rpi-4.4.y-384k tree to your build.

[jayt0808]

the links are not working... can you direct me to the new location of where these patches for 384Khz are residing?