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

shortcomings in audsrv and upsampling #528

Open
irixxxx opened this issue Feb 13, 2024 · 4 comments
Open

shortcomings in audsrv and upsampling #528

irixxxx opened this issue Feb 13, 2024 · 4 comments

Comments

@irixxxx
Copy link

irixxxx commented Feb 13, 2024

While working on PicoDrive I found the audsrv implementation a bit lacking:

  • If the audsrv backend on IOP runs low on samples it will replay the buffer over and over, right down to telling you about the buffer being miraculously filled again. New samples then don't have space in it, and the reverberating audio you get remembers me of old GSM mobiles in bad reception conditions.
    It simply can't discern "ringbuffer full" from "ringbuffer empty"... so it wraps around and around.

  • it sets the ringbuffer to half full on set_format without clearing it. Hence, there's always some old audio from the buffer played out first.

  • stopping will keep all unplayed samples and there is no way to clear the audio ringbuffer.

@AKuHAK
Copy link
Contributor

AKuHAK commented Feb 14, 2024

nice, I also noticed something similar, do you know the solution?

@irixxxx
Copy link
Author

irixxxx commented Feb 14, 2024

If I had one I would've made a PR ;-)

Most of it should be easy to fix, but it potentially breaks stuff relying on those bugs. I guess it's up to the maintainer (if there is one at all).

As for the bugs:

  • for the ringbuffer, either add an "empty" flag (e.g. a count of samples in the ringbuffer), or make sure it's only filled up to (size-1)
  • on set_format, I'd just assume the buffer to be cleared
  • likewise on stopping, or if that's not desired, add a clear buffer function

@irixxxx
Copy link
Author

irixxxx commented Feb 17, 2024

The upsamplers used to upsample to 48 KHz are also flawed:

  • the counts returned by the upsamplers are off in at least one case, e.g. for up_11025_16_mono it returns 234, but 2x512x11025/48000 is 235.
  • there is no fractional part to it, which leads to the frequency being slightly off by up to 1 input sample for 512 output samples (up to 0.5% depending on the input sample rate). Nonetheless, if the sample producer delivers the exact amount, there needs to be some glue logic for resampling (at least by throwing away some samples).

@irixxxx irixxxx changed the title shortcomings in audsrv shortcomings in audsrv and upsampling Feb 17, 2024
@irixxxx
Copy link
Author

irixxxx commented Feb 18, 2024

That upsampling stuff really bothers me. I don't think using lookup tables is a good solution to handle this.

I had a similar problem with resampling the 44.1 KHz CD audio tracks to the target sample rate. I'd suggest whoever is going to address this might want to look up my solution in the function mix_16h_to_32_resample_stereo in pico/sound/mix.c. It's also relatively independent of the source and target sample rates, so the restriction to certain rates might potentially also be lifted.

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

No branches or pull requests

2 participants