We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4710 - audio/alsa: avoid configuring hardware parameters with only a single period
Summary: audio/alsa: avoid configuring hardware parameters with only a single period
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: HG 2.1
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.10
Depends on:
Blocks:
 
Reported: 2019-07-06 03:37 UTC by Anthony Pesch
Modified: 2019-07-07 16:53 UTC (History)
1 user (show)

See Also:


Attachments
patch (4.24 KB, patch)
2019-07-06 03:37 UTC, Anthony Pesch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Pesch 2019-07-06 03:37:07 UTC
Created attachment 3867 [details]
patch

See attached patch.

This came up while porting my project (https://redream.io) to run on the Raspberry Pi 4.

To further expand on the explanation in the patch with some numbers, on the Raspberry Pi 4 a period size of 128 samples was requested with snd_pcm_hw_params_set_period_size_near which resulted in a configured period size of 444 samples. Then, snd_pcm_hw_params_set_buffer_size_near was incorrectly called with a value of 128*2 (instead of 444*2) which resulted in a final configuration of 1 period x 444 samples.

FWIW, I'm responsible for the bug (http://hg.libsdl.org/SDL/rev/b6c4568cc10b) in the first place. I've tested this fix on my local machine as well as my RPI4, but I'd appreciate a second set of eyes around my use of snd_pcm_hw_params_set_periods_min / snd_pcm_hw_params_set_periods_first as the ALSA documentation re: these wasn't very helpful; I mostly derived what to do by looking at the implementation of snd_pcm_hw_params_set_periods_near.
Comment 1 Sam Lantinga 2019-07-06 23:04:41 UTC
This sounds good, and may help fix the audio dropouts with Steam Link on Raspberry Pi. Ryan, can you verify?
Comment 2 Ryan C. Gordon 2019-07-07 15:25:59 UTC
I'm testing this in a few hours, but it looks good to me at first glance.

--ryan.
Comment 3 Sam Lantinga 2019-07-07 15:57:03 UTC
Okay, I'll go ahead and test it now on Raspberry Pi.
Comment 4 Sam Lantinga 2019-07-07 16:12:15 UTC
This has been committed for testing:
https://hg.libsdl.org/SDL/rev/3c4a4b1077cd

Ryan, can you make sure this doesn't regress on desktop Linux? Are these calls available in older ALSA implementations?
Comment 5 Ryan C. Gordon 2019-07-07 16:23:38 UTC
(In reply to Sam Lantinga from comment #4)
> Ryan, can you make sure this doesn't regress on desktop Linux? Are these
> calls available in older ALSA implementations?

These APIs showed up in February 2001, so I think we're good.  :)

https://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=a7561a9c7eaf4f0a5daa48f049c3d1e9a503380b

I'll still test this later today, regardless.

--ryan.
Comment 6 Ozkan Sezer 2019-07-07 16:28:34 UTC
(In reply to Sam Lantinga from comment #4)
>  make sure this doesn't regress on desktop Linux?

Seems to run fine on my CentOS-6.10. . Running quakespasm with
SDL_AUDIODRIVER set to alsa, I get:

SDL audio spec  : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: alsa - HDA Intel, VT1708B 8-Ch Analog, 65536 bytes buffer

.. and the sound is OK.


>  Are these calls available in older ALSA implementations?

AFAIK, they are available since alsa-lib-0.9.0
Comment 7 Ryan C. Gordon 2019-07-07 16:53:25 UTC
(In reply to Ozkan Sezer from comment #6)
> .. and the sound is OK.

Confirmed working on Ubuntu 16.04, too. I think we're solid here. Resolving this bug, thanks Anthony (and everyone else, too)!

--ryan.