Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

alpernebbi
Copy link
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
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
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
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.

None yet

2 participants