blue-debug commented on issue #18354:
URL: https://github.com/apache/nuttx/issues/18354#issuecomment-5176855601
@matiamic
Hi Michal,
Thanks for the bisect - I can confirm both findings.
The second one is my commit. Implementing AUDIOIOC_GETBUFFERINFO is
reasonable for a driver to do, but letting its absence stop playback is a
design flaw on our side. The guard is also misplaced: upper->periods only
grows on the u.pbuffer == NULL path (the upper-half ring, used by the
ALSA-lib port), so for private-buffer callers like nxplayer it was never
counting anything. Moving it into that branch fixes it without a default.
Your rp23xx_i2s.c fix works but only for that board, since
audio_i2s_ioctl() just forwards to I2S_IOCTL() - so yes, not platform
specific.
The first one is a compatibility problem with the older driver model:
before: OPEN ---------------------> RUNNING (configure optional)
after: OPEN --configure--> PREPARED --> RUNNING
Only audio_configure() sets PREPARED. That is fine when the app parses the
format itself, so mp3 and sbc are unaffected - but wav is the one case
left where parsing lives in the kernel, and pcm_decode configures the
lower half directly, bypassing the upper half. By the time START arrives
the I2S is already at 44100 but the state is still OPEN.
Always calling CONFIGURE is the right idea, just not with zeros -
rp23xx_i2s_txsamplerate() asserts on rate == 0. The defaults already
exist: 09a3bc44b4 added them to nxplayer_playraw() in 2018, and
nxplayer_playfile() bypasses them by calling nxplayer_playinternal() with
0,0,0,0. Routing both through the same path is enough. The 48000 default
is harmless - on rp23xx the PIO clock is only programmed in the START
handler, so pcm_decode's 44100 from the first buffer wins.
Both changes pushed for reference:
nuttx-apps https://github.com/blue-debug/nuttx-apps/commit/51750e75f
nuttx https://github.com/blue-debug/nuttx/commit/13b427f42
The first is downstream code we would like to upstream - it makes play and
playraw share the setup path and adds a "tone" command, so your first
problem gets fixed as a side effect. The second I wrote for this report.
Sorry that I have no RP2350 here, so this is code reading only and I
cannot confirm the audio actually comes out. I will send both as PRs.
Looking forward to your thoughts, and feel free to reach out any time.
Best regards,
Yibo Fang
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
