Hi Guenter & Reine,
Well, I hacked pretty hard on the sound support for 0.26 (so making "-audiobuf" use the GETISPACE/GETOSPACE ioctls for instance.) On drivers that support those features (like my Creative PCI driver) this works great, but apparently I really should be offering a "-stupid-linux-audio-driver" flag to go back and do it the 0.25 way with -setfragsize or whatever. I confess I don't know what the fragment size business even does, but on PCI128 it's nowhere as good as using GETISPACE/GETOSPACE.
So I propose to try to put out a "patch" of 0.26 giving the choice, perhaps using Guenter's proposed flag name. Right now I'm trying to put out a new release of fiddle~ etc, so the "patch" might not hit the web until this weekend or so...
cheers Miller
Miller Puckette writes:
Hi Guenter & Reine,
Well, I hacked pretty hard on the sound support for 0.26 (so making "-audiobuf" use the GETISPACE/GETOSPACE ioctls for instance.) On drivers that support those features (like my Creative PCI driver) this works great, but apparently I really should be offering a "-stupid-linux-audio-driver" flag to go back and do it the 0.25 way with -setfragsize or whatever. I confess I don't know what the fragment size business even does, but on PCI128 it's nowhere as good as using GETISPACE/GETOSPACE.
Hi Miller
Ah, I see. (the following is some technical blurb ...)
<blurb>
I didn't dig too much into the code and therefore didn't realize what the GETISPACE/GETOSPACE business is really about.
I just never thought of solving the audiobuffer problem this way.
Apparently this works very good for bus master PCI cards, like the PCI128,
but it may give problems with ISA cards, because they use the PC's
DMA to transfer data.
Information how much data is already transported can only be given
accurately blockwise (or rather fragment wise).
In other situations some drivers ask the DMA how much data is
transferred, which is, considering the slowness of ISA DMA suboptimal.
Some drivers may just give you numbers rounded up/down to the
fragmentsize.
In this situation it is better to use small fragmentsizes, and
more fragments. Fragmentsize times fragmentnumber gives you the
number of bytes in your audiobuffer.
The whole fragmentsize/fragmentnumber business is sort of alchemy, and nobody knows which is the perfect combination of size and number. (Reine lately supposed a setting which was used in Bill Schottsteads snd program and is working good for his setup).
</end of blurb>
My proposal is therefore to use "-fragmentnumber" and "-fragmentsize" for the OSS version, together with a README file which lists some settings for different soundcards. (We can collect them here at the list).
.... and work on the ALSA interface
Guenter
On 18 Aug, Miller Puckette wrote:
Hi Guenter & Reine,
Well, I hacked pretty hard on the sound support for 0.26 (so making "-audiobuf" use the GETISPACE/GETOSPACE ioctls for instance.) On drivers that support those features (like my Creative PCI driver) this works great, but apparently I really should be offering a "-stupid-linux-audio-driver" flag to go back and do it the 0.25 way with -setfragsize or whatever. I confess I don't know what the fragment size business even does, but on PCI128 it's nowhere as good as using GETISPACE/GETOSPACE.
To make my homebrew play work with my Thinkpad 560 (133mHz pentium) i added
svar=(2<<16) | (14) ; ioctl(sfh,SNDCTL_DSP_SETFRAGMENT,&svar);
to my InitPlay function. This ioctl should, because of something, be used before the others (SETFMT,SPEED etc).
Here are my guesses: The 2 in (2<<16) refers to number of fragments. The 14 refters to size of fragments. 14 bits is 16384. (correct me if im wrong). It seems like if I stay on a total of 32768 (=2*16384) I can use a number of variations like svar=(4<<16) | (13);
By some odd reason I get funny glitches I've never heard before (not like over/underrun clicks) if the total buffer size gets higher than 32768. If SNDCTL_DSP_SETFRAGMENT is not used my Linux chooses to use twice the size if 32768, ok for most soundcards.
To get a hint of whats happening we can use
{ audio_buf_info info;
ioctl(sfh,SNDCTL_DSP_GETOSPACE,&info); printf("%d %d &d &d\n",info.fragments,info.fragstotal, info.fragsize,info.bytes);
}
Sorry if I pestered you about obvius things.
Reine
So I propose to try to put out a "patch" of 0.26 giving the choice, perhaps using Guenter's proposed flag name. Right now I'm trying to put out a new release of fiddle~ etc, so the "patch" might not hit the web until this weekend or so...
cheers Miller
reine@mbox314.swipnet.se writes:
Here are my guesses: The 2 in (2<<16) refers to number of fragments. The 14 refters to size of fragments. 14 bits is 16384. (correct me if im wrong).
this is exactely right. The parameter is fragmentnumber<<16 + log2(fragmentsize)
It seems like if I stay on a total of 32768 (=2*16384) I can use a number of variations like svar=(4<<16) | (13);
This is funny behaviour and will get you rather high latency (assuming that you can't use the GETOSPACE calls either)
BTW, what driver are you using ?
Guenter
-
Guenter Geiger -
Miller Puckette -
reine＠mbox314.swipnet.se