--- 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 th
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
--- 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, whic
--- 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
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!
htt
At Fri, 7 Feb 2003 13:58:48 + (GMT),
Chris Rankin wrote:
>
> --- 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 des
>> 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-blo
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 th
--- 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 (unl
>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
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 exactl
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
> 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
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
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:
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
16 matches
Mail list logo
