how to find the maximum fragment size for SNDCTL_DSP_SETFRAGMENT?
The guide of 4front's web page says total_buffer_size/2. I know the kernel buffer size used to be defined at kernel compile time. How does one go about determining it now? DSP_GETBLKSZ? Does DSP_GETBLKSZ still fix the block size so that the device must be closed and opened again in order to set the fragment size?
Britton Kerin
Quoted 4 lines · Britton
The guide of 4front's web page says total_buffer_size/2. I know the kernel buffer size used to be defined at kernel compile time. How does one go about determining it now?
DSP_GETBLKSZ?
Wy would you need this information?
If you like to get as large fragments as possible just set the fragment size to very big. The driver will then select the largest one it could support.
However changing the fragment size bigger than the default doesn't give any benefit. You can always write/read multiple fragments at time to get the same effect.
Quoted 3 lines
Does
DSP_GETBLKSZstill
fix the block size so that the device must be closed and opened again in order to set the fragment size?
This is the current and future behaviour.
Best regards,
Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
Quoted 7 lines · Hannu Savolainen
Quoted 4 lines · Britton
The guide of 4front's web page says total_buffer_size/2. I know the kernel buffer size used to be defined at kernel compile time. How does one go about determining it now?
DSP_GETBLKSZ?Wy would you need this information?
I'm letting my users specify the fragment size, and I try to check things like whether what they specify is out of range before actually making the syscall.
Quoted 3 lines
If you like to get as large fragments as possible just set the fragment size to very big. The driver will then select the largest one it could support.
Ok, I didn't know it would do that. I guess there is no real reason the user needs to know if their large fragment size was not actually set (they already get a warning if the fragment size they request is big enough that it will likely cause latency). That behavior might be something to add to the 4front page.
Quoted 8 lines
However changing the fragment size bigger than the default doesn't give any benefit. You can always write/read multiple fragments at time to get the same effect.
Quoted 3 lines
Does
DSP_GETBLKSZstill
fix the block size so that the device must be closed and opened again in order to set the fragment size?This is the current and future behaviour.
Thanks,
Britton