Skip to content

Rockchip/rk3399-gru-sound: Use 48KHz sample rate for all devices#201

Open
alpernebbi wants to merge 1 commit intoalsa-project:masterfrom
alpernebbi:rk3399-gru-sound-sample-rate
Open

Rockchip/rk3399-gru-sound: Use 48KHz sample rate for all devices#201
alpernebbi wants to merge 1 commit intoalsa-project:masterfrom
alpernebbi:rk3399-gru-sound-sample-rate

Conversation

@alpernebbi
Copy link
Copy Markdown
Contributor

The rk3399-gru-kevin board has problems when trying to simultaneously playback and record audio with the default PulseAudio sample rate of 44.1KHz. When the following command is run, the playback starts a few seconds after the recording finishes.

arecord -vvv -d 4 /dev/null & sleep 0.2; speaker-test -l 1 -p 100000 -t sine

When the sample rates are set to 48KHz either with PA configuration or in the UCM, playback and recording both start immediately. Another example is when a music player is running and we start arecord, the music starts stuttering but arecord can't record anything either.

Apparently, this is a hardware limitation due to the I2S lines being shared between the devices. Set all the device rates to 48KHz like Chrome OS does to make things work smoothly.

[1] https://chromium-review.googlesource.com/389695
[2] https://chromium-review.googlesource.com/898682

The rk3399-gru-kevin board has problems when trying to simultaneously
playback and record audio with the default PulseAudio sample rate of
44.1KHz. When the following command is run, the playback starts a few
seconds after the recording finishes.

    arecord -vvv -d 4 /dev/null & sleep 0.2; \
    speaker-test -l 1 -p 100000 -t sine

When the sample rates are set to 48KHz either with PA configuration or
in the UCM, playback and recording both start immediately. Another
example is when a music player is running and we start `arecord`, the
music starts stuttering but `arecord` can't record anything either.

Apparently, this is a hardware limitation due to the I2S lines being
shared between the devices. Set all the device rates to 48KHz like
Chrome OS does to make things work smoothly.

[1] https://chromium-review.googlesource.com/389695
[2] https://chromium-review.googlesource.com/898682

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
@perexg
Copy link
Copy Markdown
Member

perexg commented Aug 23, 2022

It should be handled in the driver - if the rate is already set in one direction, the driver should lock this rate for the other direction, too. I would fix the driver at first.

@alpernebbi
Copy link
Copy Markdown
Contributor Author

if the rate is already set in one direction, the driver should lock this rate for the other direction

That sounds reasonable, I'll try to do it. But setting all rates to 44100 in the UCM config still results in the problematic behaviour, does that mean anything to you?

@perexg
Copy link
Copy Markdown
Member

perexg commented Sep 5, 2022

If you can reproduce the problem using different applications and ALSA utilities, it looks like a driver issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants