Paul Davis wrote: Paul Davis, thanks for your message. Im working with acquisition of voice frames to send in Internet network. It's a VOIP system under Linux. In my system I didn't use any kind of special hardware (like VOVIDA http://www.vovida.org) to colect the sound of microphone, just the soundcards like Soundblaster. When I read the frames of voice of device /dev/audio I use the buffer lenght of 4096 like the OSS Guide talks. I'm very confused to discover which is the best packet lenght to send across the Internet. I read the paper of David Minoli but sincerily didn help. Now I'm only working with ADPCM codec but in the future I want to study GSM and other codecs to implement QoS Dynamic in the endpoints. The question is which is the best soundcard Buffer to use with ADPCM codec to send across the Internet. Thanks, Alessandro Vivas Andrade

On Wed, Feb 26, 2003 at 01:01:45AM +0100, Martijn Sipkema wrote: ISO packets are a fixed size, so there will be a constant number of frames per packet. - Steve

On Wed, Feb 26, 2003 at 11:17:31 +0100, Martijn Sipkema wrote: The bottom level packets are sent at fixed time intervals (obviously, corresponding to the frame clock of the bus), but these packets are tiny and you get millions of them per second. A useful packet of audio data will be made up of a bunch of these. According to the mLAN spec you need a buffer of around ~250us (depending on format) to collate the packets. - Steve

On Wed, Feb 26, 2003 at 12:38:38 +0100, Martijn Sipkema wrote: Why? Surely its much easier to wait until you have n samples and then send them round. The extra 250us of latency is hardly punishing. You must do that where you have a soundcard<->mLAN bridge in any case, in order to sync the graphs. IMHO if jack makes things hard for app developers by forcing them to deal with odd sized data blocks then its not doing its job. As we have discussed on the jack list there are a number of situations where you cant reliably or efficiently handle variable block sizes. - Steve

i don't want you to shut about it. its a very important design decision. as i understand it, VST is only variable to allow for automation. And if you follow the discussion here about XAP and elsewhere about PTAF, you will see that many people consider this a mistake that comes from not using "events" in the correct way. i feel that it should be the job of ALSA to handle period sizes. if it doesn't do a good job, it should be fixed. if we ask for a wakeup every time 1024 frames are available, and the interrupts occur at 420, 840 and 1260 frames, then we should be woken up on the third interrupt, process 1024 frames of data, and go back to sleep. the h/w driver should handle this, not JACK. the latency behaviour will be just as requested by the user. --p

sure, but then ALSA does the same. the question is whether to export this detail up to applications or not. thats because you decided to write a simple driver that didn't fit into the ALSA scheme. the ALSA scheme deliberately offers such capabilities, partly to handle devices like USB audio interfaces. if you had written your driver as part of ALSA, it would not have to have support for this - the "midlevel" ALSA code takes care of that stuff. something has to specify when to wake a task blocked on I/O to the device. you can wake it up every interrupt, every N seconds, or every N frames (with frames-per-interrupt level resolution). ALSA allows you to do any of these. which one is most appropriate, and whether it should be set by a "control" application (common on windows/macos) or by the application using the device driver is subject to reasonable disagreement by sensible people. agreed. but by the same argument, if the variability in the block size was too great, we would also see too much variation in cycles-per-frame due to processing overhead per interrupt, which will also kill us. so the question seems to be: how much variation is acceptable, and what should be responsible for handling it? a device which interrupted at random intervals would simply not work; one that interrupts at 420 frames +/- 5 frames might be OK. should the h/w driver hide the variation, or should each application be willing to deal with it? most applications would have no problem, but there is an interesting class of applications for whom it poses a real problem that i think requires a common solution. i'm not sure what that solution should be. --p

;-) I wish you guys had carried this conversation on with a new title as I think this has nothing at all to do with 1394. ;-) Just so everyone else not conversing here is clear, the size of the packet transmitted across the 1394 bus and the size of a Jack data block need have nothing to do with each other. Using 61883, or even a home grown protocol like I am/was working on, 1394 packets will be given timestamps for presentation at the receiving end, and 1394 can transmit these packets in full Jack data block sizes, or smaller to make more efficient use of 1394 bus bandwidth. Just being clear that 1394 and this conversation _can_ _be_ completely orthogonal. (And should be IMO) Thanks, Mark

Because: - I think ALSA is not that well documented. - I'd rather see a combination of a device specific kernel driver and a user-space driver than a common kernel interface. I'm not comparing ALSA to OSS. And having user-space drivers doesn't prevent code sharing. I just don't like the common device file interface. --ms

heard variable If I understand that code correctly then you wait for 'FFT frame size' samples to be available and then process that entire FFT frame. This will not introduce a variable amount of processing time/sample and will not work for large FFT frames. Adding en extra FFT frame delay and processing asynchronously would solve this. I'm not saying this is easy, but I don't think an algorithm like this should rely on a callback being one (or more) FFT frame long. I think is at least as valid an argument as a possible increase in performance for some algorithms on some hardware. EASI is a hardware abstraction framework from Emagic. It was meant to be a open alternative to ASIO. It didn't make it and now that Emagic has been acquired by Apple it is no longer supported by Emagic I guess, as I can not find anything about it on their site anymore. http://www.sipkema-digital.com/~msipkema/EASI_99may25.pdf --ms

(depending same not Well, I think it is. And I've mentioned it a couple of times also. Why? This will always introduce a fairly large latency unless you are willing to accept process time/sample to vary and thus be able to do significantly less processing. Which is the common case. When using more than one interface then there needs to be buffering. When syncing audio to video there needs to be buffering also. This should be done in the application such as in OpenML ( http://www.khronos.org ). Is has nothing to do with one or more applications. Non-const size (frames) callbacks for just as well with more applications (using JACK). I've made my point, several times. Nobody thinks I'm right, so I'll shut up about it. I still think it is a mistake... --ms