Page MenuHomeFreeBSD

snd_emu10kx: Make sure the block count and size cover the whole buffer
ClosedPublic

Authored by christos on Sat, Sep 5, 2:38 PM.
Tags
None
Referenced Files
F171084742: D59444.id185920.diff
Tue, Sep 8, 2:50 PM
F171061347: D59444.id.diff
Tue, Sep 8, 11:35 AM
F171044335: D59444.id.diff
Tue, Sep 8, 9:09 AM
F171029991: D59444.diff
Tue, Sep 8, 7:10 AM
Unknown Object (File)
Mon, Sep 7, 8:05 PM
Unknown Object (File)
Mon, Sep 7, 4:39 PM
Unknown Object (File)
Mon, Sep 7, 4:35 PM
Unknown Object (File)
Mon, Sep 7, 4:09 PM
Subscribers

Details

Summary

The playback voices always loop over the whole EMU_PLAY_BUFSZ buffer,
but emupchan_setblocksize() only recorded the new block size and left
the block count as it was set up by emu_vinit(). The blocks then no
longer covered the whole buffer, and the part they left out was played
without ever being written to, which became audible as distortion once
playback started going through a virtual channel.

Resize the buffer, so that the block count and size always cover it.

PR: 287687
MFC after: 1 week
Sponsored by: The FreeBSD Foundation

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 76563
Build 73446: arc lint + arc unit

Event Timeline

The PR reporter says the patch fixes his issue.

Which commit introduced the regression? A Fixes: tag should be included, I believe.

Which commit introduced the regression? A Fixes: tag should be included, I believe.

I could reference 02d4eeabfd73 ("sound: Allocate vchans on-demand"), but this commit only surfaced an existing bug which apparently was there since the importing of the driver, so does it make sense to add a "Fixes" tag in this case?

Which commit introduced the regression? A Fixes: tag should be included, I believe.

I could reference 02d4eeabfd73 ("sound: Allocate vchans on-demand"), but this commit only surfaced an existing bug which apparently was there since the importing of the driver, so does it make sense to add a "Fixes" tag in this case?

It's probably borderline. The point of Fixes isn't to assign blame per se but to help simplify backporting: if I backport commit A, which introduced some regression, then I almost always want to backport commit B, which fixed the regression in A, as well. Whether or not the bug itself was introduced by A or just uncovered by A is not very important. So I'd lean towards having a Fixes tag. The commit log message can explain the details.

This revision is now accepted and ready to land.Mon, Sep 7, 2:09 PM