Re: [Alsa-devel] Rawmidi mystery

2003-02-07 Thread Jaroslav Kysela
On Thu, 6 Feb 2003, Frank Neumann wrote: And YES, that did the trick! Thanks a lot, Clemens. Looks like the drain() takes a lot longer than I'd have expected (my thought was that it would return right after the last command bytes have been sent out, and that the incoming stream would be held

Re: [Alsa-devel] Rawmidi mystery

2003-02-07 Thread Clemens Ladisch
Frank Neumann wrote: PS: I checked with gettimeofday(): The snd_rawmidi_drain() takes about 47-49ms on my system..quite long, huh? I mean, the command sequence is just 7 bytes, that's about 2.24ms of raw MIDI transfer time.. There are two possibilities how the _drain() can be implemented: 1)

Re: [Alsa-devel] Rawmidi mystery

2003-02-07 Thread Jaroslav Kysela
On Fri, 7 Feb 2003, Clemens Ladisch wrote: Frank Neumann wrote: PS: I checked with gettimeofday(): The snd_rawmidi_drain() takes about 47-49ms on my system..quite long, huh? I mean, the command sequence is just 7 bytes, that's about 2.24ms of raw MIDI transfer time.. There are two

Re: [Alsa-devel] pcm_jack plugin attempt

2003-02-07 Thread Maarten de Boer
Please, see to refine code in pcm_dmix.c. You cannot do it with your way. The refine means that it reduces given configuration and if no valid configuration for given parameter exists, then the result value has to be empty (or not set). Okay, so, where I tried to do something like (not

Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes

2003-02-07 Thread Paul Davis
The API does not *need* to set the FD_CLOEXEC flag, and so it should not. It is the height of arrogance to assume that something has no use simply because you can't imagine using it. there's a little detail you're forgetting. unless the hw supports multi-open and the current number of subunits is

Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes

2003-02-07 Thread Chris Rankin
--- Paul Davis [EMAIL PROTECTED] wrote: there's a little detail you're forgetting. unless the hw supports multi-open and the current number of subunits is below the limit of the number of opens, then having the descriptor will cause all other attempts to access the device to block (unless

Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes

2003-02-07 Thread Sebastian Kapfer
On Thu, 6 Feb 2003 23:10:34 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote: --- Sebastian Kapfer [EMAIL PROTECTED] wrote: I can find a use for stdio FD's in the new process either. The exec'd process can't even know which FD corresponds to which file. I'm assuming from the context of

Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes

2003-02-07 Thread Paul Davis
there's a little detail you're forgetting. unless the hw supports multi-open and the current number of subunits is below the limit of the number of opens, then having the descriptor will cause all other attempts to access the device to block (unless they explicitly request non-blocking open,

[Alsa-devel] Where to report?

2003-02-07 Thread Mark Knecht
Hi, Is Alsa-Dev the right place to report problems with Linux MIDI? (Such as stuck note problems with soft synths.) Thanks, Mark --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!

Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes

2003-02-07 Thread Chris Rankin
--- Paul Davis [EMAIL PROTECTED] wrote: not clearly so. there are very few resources accessed via a file descriptor that require this being done. You think? Try unmounting a filesystem or unloading the ide-cd kernel module if (say) xscreensaver has been spawned by (say) xine, but xine has

Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes

2003-02-07 Thread Chris Rankin
--- Sebastian Kapfer [EMAIL PROTECTED] wrote: Setting FD_CLOEXEC automatically doesn't make the library less powerful. You can still unset the flag yourself __if you really need the feature__ of inherited ALSA FD's. But wouldn't FD_CLOEXEC be the reasonable default setting, which is

[Alsa-devel] Re: [Alsa-user] sb live dma buffer alloc failure?

2003-02-07 Thread Brian J. Tarricone
Takashi Iwai wrote: which kernel version are you using? 2.4.20 - it's a heavily patched one, tho (out of gentoo's portage). should i try a vanilla kernel? the new code on rc7 simply tries allocation via vmalloc(). if it fails, it means that the system resource is really exhausted. or, there

Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes

2003-02-07 Thread Chris Rankin
--- Takashi Iwai [EMAIL PROTECTED] wrote: i don't think it's a bug of the alsa-lib, too. it's a bug of mplayer. mplayer should be fixed. period. Hooray! ;-) but, the problem is that this kind of bugs can be rarely found (nor appear). I found lsof to be a most useful tool. on the

[Alsa-devel] Re: [Alsa-user] sb live dma buffer alloc failure?

2003-02-07 Thread Takashi Iwai
At Wed, 05 Feb 2003 02:15:27 -0500, Brian J. Tarricone [EMAIL PROTECTED] wrote: forgive me for cross-posting, but i've found references to this problem on both lists, so... this should go to alsa-devel, not alsa-users... so then i noticed rc7, and tried that (unpatched, fresh from the

[Alsa-devel] Re: [Alsa-user] sb live dma buffer alloc failure?

2003-02-07 Thread Takashi Iwai
At Wed, 05 Feb 2003 16:42:48 +, [EMAIL PROTECTED] wrote: Hi, I have exactly the same problem, I was considering posting here. My config is 2.4.21pre4 (HIGHMEM) alsa 0.9.0rc7 , my system has 1GB memory. (the prb was the same with 2.4.21pre3 and 0.9.0rc6) did you have the exactly same