accidental revert of Presonus 1824c quirk ?

accidental revert of Presonus 1824c quirk ?

[fenugrec]

Hi,
I'm looking at this repo
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/
and it seems a recent merge reverted a commit ?

Original commit
  d1d6ad7f6686e208aba06b7af3feef7a7cba61cf ALSA: usb-audio: don't apply interface quirk to Presonus S1824c
Merge that removes the added quirk:
  329bdcbbd229731dc5a8b6753aa2409f00869331 Merge branch 'for-linus' into for-next

- Was this on purpose ?
- Should I just be looking at a different repo to hack on this driver (Presonus series) ?

Thanks,

Re: accidental revert of Presonus 1824c quirk ?

[Takashi Iwai]

On Wed, 07 Jan 2026 17:57:41 +0100,
fenugrec@mail.com wrote:
> 
> Hi,
> I'm looking at this repo
> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/
> and it seems a recent merge reverted a commit ?
> 
> Original commit
>   d1d6ad7f6686e208aba06b7af3feef7a7cba61cf ALSA: usb-audio: don't apply interface quirk to Presonus S1824c
> Merge that removes the added quirk:
>   329bdcbbd229731dc5a8b6753aa2409f00869331 Merge branch 'for-linus' into for-next
> 
> - Was this on purpose ?

Looks like yes.  The quirk was confirmed to be superfluous for 1824c.


Takashi

Re: accidental revert of Presonus 1824c quirk ?

[fenugrec]

> Looks like yes.  The quirk was confirmed to be superfluous for 1824c.

Ah thanks, I finally found the commit that explained the removal. However,
testing here, it does seem to be required.

Test command :
    arecord -r 96000 -d 2 -D 'sysdefault:CARD=S1824c' -c 2 test.wav -f S24_LE

test 1) compiling at tag v6.18 (7d0a66e4bb9081d75c82ec4957c50034cb0ea449)
  fails; interface becomes non responsive, and when arecord exits, its display shows maxed-out bargraphs

test 2) same tag, but reverting d1d6ad7f6686e208aba06b7af3feef7a7cba61cf
  records fine. Have not tested exhaustively.

my 1824c has fw version 3.11 .

I've BCC'd Roy here so we can refine our tests and find out what's going on.


Cheers,

Re: accidental revert of Presonus 1824c quirk ?

[Roy Vegard Ovesen]

On Thu, Jan 08, 2026 at 04:33:36PM +0100, fenugrec@mail.com wrote:
> Ah thanks, I finally found the commit that explained the removal. However,
> testing here, it does seem to be required.
> 
> Test command :
>     arecord -r 96000 -d 2 -D 'sysdefault:CARD=S1824c' -c 2 test.wav -f S24_LE
> 

I did the same arecord test on arch with kernel version 6.18.3-arch1-1,
1824c firmware 3.11. And that recorded fine.
I also tried all other sampling rates and 18 channel recordings, and eventually I managed
to "break" the interface, so that I had to power cycle it to get it running again.

I'll have to do more testing to find out how to reliably "break" it.

-- 
Roy Vegard

Re: accidental revert of Presonus 1824c quirk ?

[fenugrec]

Thanks Roy !

> same arecord test on arch with kernel version 6.18.3-arch1-1,
> 1824c firmware 3.11. And that recorded fine.

That is so strange ! At least we're running the exact same system & kernel so we can rule out a few things .

I wonder if pulseaudio/pw settings could have an impact on the hopping between altsettings ?
I'm not running pipewire, and in pulse's pavucontrol I had the presonus "profile" disabled.


Cheers,

Re: accidental revert of Presonus 1824c quirk ?

[Roy Vegard Ovesen]

On Fri, Jan 09, 2026 at 01:21:38AM +0100, fenugrec@mail.com wrote:
> That is so strange ! At least we're running the exact same system & kernel so we can rule out a few things .
> 
> I wonder if pulseaudio/pw settings could have an impact on the hopping between altsettings ?
> I'm not running pipewire, and in pulse's pavucontrol I had the presonus "profile" disabled.

Normally I'm running pw, but for this testing I have stopped pipewire completely
and use alsa directly. So far I have observed:

- Reaper, Ardour and arecord are working fine.

- When testing arecord I have to use -D plughw:S1824c to get direct control of
the device. If I use -D sysdefault:CARD=S1824c it always uses sampling rate 176400
for the device and, I assume, converts in software to the sample rate that I requested.

- By monitoring USB traffic with Wireshark I see that when for example I run arecord
it first checks and sets the clock selector, then it checks and sets the sample
rate, next it sets the interface with altsetting according to the sample rate.
When recording is done it sets the interface with altsetting to 0.

I'm wondering if one way to make the 1824c panic is by setting an invalid
sample rate and interface/altsetting combination. For example setting
sample rate to 96000 and interface/altsetting to 1/1 for playback
and/or 2/1 for recording. Are you able to monitor USB traffic when
arecord fails and check if it tries to set an invalid sample rate
and interface/altsetting combo?

So far I have not been able to break the device in this testing session,
but I will crack on.

-- 
Roy Vegard

Re: accidental revert of Presonus 1824c quirk ?

[fenugrec]

[Solved] For future reference:
I was wrongly suspecting the linux driver, for what turned out to be an odd hardware issue.

I've documented full details here https://qcte.ca/audio/presonus_1824c/#chapter-2-clocks
but the main points are :

1- my 'arecord' test was flawed; specifying -D sysdefault:... doesn't necessarily change sample rate as expected
2- the problem was present with a win10 VM as well as another (native) win10 machine
3- the problem is caused by a distorted clock signal internal to the device.
4- the fix was to replace a component (ferrite bead) driving that clock.

regarding #1, I never found a good combination of args for arecord that works as expected:
with 'plughw:CARD=S1824c', it sometimes doesn't change the samplerate;
with 'hw:CARD=S1824c', it's very picky about # of channels and sample format;
(why does it insist on 32-bit float, when the USB-audio descriptor defines 24-bit signed ??)

Some arguments were always helpful: '-vv --dump-hw-params --disable-resample'

For me, this is solved. Thanks Roy for helping me look into this.

If you have an 1810/1824 and an oscilloscope, contact me off-list, I'm curious to compare notes !