Re: [Alsa-devel] usb-audio: variable periodsize / nframes per callback can shorten latency times
hmm, it's not so easy, since this will break also the assumption of constant period frames by applications. if we introduce the time-based period size, it won't work as compatible as older one, e.g. jack wouldn't run properly if the period size changes dynamically. this isn't true, or if it is true, it can be fixed fairly easily. what you might mean is that some JACK clients won't run well under such circumstances, but the JACK alsa driver/client is written to present uniform period sizes to JACK. the fact that the ALSA driver itself doesn't do this won't affect JACK - we will instead still break up the stream into uniform-sized chunks. --p --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] usb-audio: variable periodsize / nframes per callback can shorten latency times
At Tue, 20 Aug 2002 12:30:11 +0200 (CEST), Tim Goetze wrote: Takashi Iwai wrote: How can we implement the latency-optimal behaviour with alsa-driver framework? Can we implement something like a snd_1ms_elapsed() routine (called from USB-interrupt), which in turn triggers a waiting app with the available period size (which would be 44 or 45 frames for 44100Hz)? I would like to see this in ALSA / JACK. What do you think? hmm, it's not so easy, since this will break also the assumption of constant period frames by applications. if we introduce the time-based period size, it won't work as compatible as older one, e.g. jack wouldn't run properly if the period size changes dynamically. hence, this should be handled in a special case. With the current setup and cycle code for mmap'd IO (like Jack for example does it), is it possible to use these devices at all? on 48kHz my usb speaker worked fine with 1ms or 2ms period size (not under high loads, though), since the frames per urb becomes integer in this case. on 44.1kHz xrun could happen. What kind of hw/sw params, especially period size, should one set? the frequency aligned to 1000Hz. Can one choose larger period sizes (45 frames/cycle is too tough for a userspace process, at least on this box)? of course, depending on the kernel :) in theory, 1ms latency is enough possible. ciao, Takashi --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] usb-audio: variable periodsize / nframes per callback can shorten latency times
At Tue, 20 Aug 2002 13:34:03 +0200 (CEST), Tim Goetze wrote: Takashi Iwai wrote: With the current setup and cycle code for mmap'd IO (like Jack for example does it), is it possible to use these devices at all? on 48kHz my usb speaker worked fine with 1ms or 2ms period size (not under high loads, though), since the frames per urb becomes integer in this case. on 44.1kHz xrun could happen. Yeah, a differing number of frames/cycle makes things hairy. But if one sets a period size of 45/90 frames/cycle and accepts 44/88/89 as well, things should work OK, shouldn't they? well... for that, you have to know how much data to be written _before_ actually you writing it. i.e. you need an extra step, query the (rest) period size - then write/read, instead of always writing the same amount of data. What kind of hw/sw params, especially period size, should one set? the frequency aligned to 1000Hz. You mean divided by 1000, rounded up to the nearest integer, right? yes. Takashi --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] usb-audio: variable periodsize / nframes per callback can shorten latency times
Hi, usb iso transfers happen every 1ms (USB1.1) ( or at multiples of 125µs for USB2.0). this timing is fixed and leads to a variable amount of frames available at interrupt. looking at 44100Hz on USB 1.1, we receive/send 44 frames on 9 of 10 USB-interrupts and 45 frames on 1 of 10 USB-interrupts. on first sight 48000Hz seams to lead to a constant 48 frames per interrupt. this does not remain true if the USB-audio device is in sync to an externally connected device (digital in). the current usb-audio mimics constant period size in the USB-interrupt routines by calling snd_period_elapsed() only, if at least full period sizes are transfered on the usb. this good for constant period-size compatibility but leads to sub-optimal latency: i.e. for capture worst case, audio apps start working 1ms later than possible. How can we implement the latency-optimal behaviour with alsa-driver framework? Can we implement something like a snd_1ms_elapsed() routine (called from USB-interrupt), which in turn triggers a waiting app with the available period size (which would be 44 or 45 frames for 44100Hz)? I would like to see this in ALSA / JACK. What do you think? regards, Karsten __ Gesendet von Yahoo! Mail - http://mail.yahoo.de Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
