Re: [Alsa-devel] Rawmidi mystery
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 by the buffer (4096 bytes, right) for a little while, so I didn't expect any losses there. I find this a little odd - especially since it was not the _beginning_ of the stream that is missing, but a couple of bytes a little later. But, what the heck - it works now, I learnt something - thanks! :-) Greetings, Frank 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.. It looks like a serious bug in the driver. Could you resend me privately your utility again? Thanks. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi mystery
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) The driver knows when the FIFO is empty, and waits until then, or 2) Nothing is known, so ALSA simply waits for 50 ms. Currently, there isn't any driver which implements 1). :-( Clemens --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi mystery
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 possibilities how the _drain() can be implemented: 1) The driver knows when the FIFO is empty, and waits until then, or 2) Nothing is known, so ALSA simply waits for 50 ms. Currently, there isn't any driver which implements 1). :-( Yes, you got it. I forgot this algorithm. Unfortunately, the most of cards don't allow us to read the FIFO size / state, so it's a bit problematic to determine the real time when all data are flushed to device. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] pcm_jack plugin attempt
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 complete code)
snd_pcm_format_mask_t format_mask = { SND_PCM_FMTBIT_FLOAT };
snd_pcm_format_mask_t access_mask;
err = _snd_pcm_hw_param_set_mask(params, SND_PCM_HW_PARAM_FORMAT,
format_mask);
snd_pcm_access_mask_none(access_mask);
snd_pcm_access_mask_set(access_mask, SND_PCM_ACCESS_MMAP_INTERLEAVED);
snd_pcm_access_mask_set(access_mask, SND_PCM_ACCESS_MMAP_NONINTERLEAVED);
err = _snd_pcm_hw_param_set_mask(params, SND_PCM_HW_PARAM_ACCESS,
access_mask);
err = _snd_pcm_hw_param_set_minmax(params, SND_PCM_HW_PARAM_RATE,
44100, 0,
44100, 1);
(which does seem to work though!)
I should do something like:
static snd_mask_t access = { .bits = {
(1SNDRV_PCM_ACCESS_MMAP_INTERLEAVED) |
(1SNDRV_PCM_ACCESS_MMAP_NONINTERLEAVED) |
(1SNDRV_PCM_ACCESS_RW_INTERLEAVED) |
(1SNDRV_PCM_ACCESS_RW_NONINTERLEAVED),
0, 0, 0 } };
snd_interval_t t;
snd_pcm_format_mask_t format_mask = { SND_PCM_FMTBIT_FLOAT };
t.openmin = 0;
t.openmax = 0;
t.empty = 0;
t.integer = 1;
t.min = 44100;
t.max = 44100;
snd_mask_refine(hw_param_mask(params, SND_PCM_HW_PARAM_ACCESS), access);
snd_mask_refine(hw_param_mask(params, SND_PCM_HW_PARAM_FORMAT),format_mask);
snd_interval_refine(hw_param_interval(params,SND_PCM_HW_PARAM_RATE),t);
?
This doesn't work for the rate though:
aplay: interval_inline.h:79: snd_interval_max: Assertion `!snd_interval_empty(i)'
failed
What am I doing wrong?
What I have now working is a plugin the has no slave and that writes the data to file
(later
this will be jack, now it's just for testing), in refined the format and rate.
Maarten
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes
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 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, which means they then have to unset that flag for normal application operation). this means that even if the parent has closed the ALSA device, the child still (unwittingly) has it open. its easy to imagine situations where the user will be completely puzzled to find that another program cannot start up because they believe they exited from the previous audio program. they don't understand that the child process it started (say, a bug reporting system) still has the device open. this is quite different from how file descriptors that refer to disk files, ttys and most other devices operate. of course, its questionable whether the block-on-open approach is correct, but so far discussions on this list have supported it. --p --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes
--- 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 they explicitly request non-blocking open, which means they then have to unset that flag for normal application operation I hadn't forgotten. The situation to which you are referring is called a bug in the *application*. Determining the destinies of resources, delivery of signals etc when spawning child processes is the application-programmer's responsibility. And yes, I have tracked down bugs like this before. And I *did* fix the application. Chris __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes
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 your message that you meant CAN'T find a use ... either. You're right, sorry :) But the whole point of a general purpose API (which is what libc is and presumably is what ALSA aspires to have) is to support *ALL* possible uses, whether you can imagine them or not. 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 correct for 99% of all applications? It is the height of arrogance to assume that something has no use simply because you can't imagine using it. I'm not implying that this feature should be banned... in fact it can't be banned. As long as the programmer can retrieve the underlying FD number from the ALSA library, he can always (un)set FD_CLOEXEC. My point is that the current default behaviour is (at least IMHO) unfortunate. -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes
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, which means they then have to unset that flag for normal application operation I hadn't forgotten. The situation to which you are referring is called a bug in the *application*. not clearly so. there are very few resources accessed via a file descriptor that require this being done. the fact that an application has to understand this only adds to the problems with the block-on-open design. --p --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Where to report?
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! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes
--- 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 carelessly leaked a file descriptor to a movie file, DVD device etc. (But not with current versions of xine... ;-) the fact that an application has to understand this only adds to the problems with the block-on-open design. Save me from application programmers who don't understand what they're doing... ;-/! Chris __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes
--- 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 correct for 99% of all applications? Most of those 99% of all applications don't spawn child processes at all and so don't care one way or another. (And did you know that 98.68% of all statistics are invented ;-)?) All of the remaining applications should be considering what will happen to their resources on exec(), and I see no reason why careless programmers should have a few of their bugs swept under the rug for them. Chris __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [Alsa-user] sb live dma buffer alloc failure?
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 might be memory leak or so... hmm... well, rc7 has locked for me very shortly after system startup, top reports plenty (200mb) free, so this shouldn't be a free resource issue. it seems to only occur if i try to rapidly open and close the device (when i say 'rapidly' i mean about once per second for about 10-25 seconds). it's sub-ideal, but i'm using esd for now (with a really high timeout for releasing the pcm device) to avoid the excessive reopening behaviour. thanks for your help - please let me know of any other ways i can try to gather information. -brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [BUG] alsa-lib leaves sound device open for child processes
--- 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 contrary, if FD_CLOEXEC is set, you'll be able to notice what's On the contrary, if FD_CLOEXEC is set then these kind of bugs will be harder to spot because the library will bury the bodies. But the application bugs will still be there. Chris __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [Alsa-user] sb live dma buffer alloc failure?
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 website). things are somewhat worse. i load up xmms, and start playing mp3s. things seem fine, playing for hours until i get bored of some songs, put it on random play, and keep hitting next song until i find something i feel like listening to. if i press 'next' roughly once per second, after about 15-20 songs xmms locks up hard and jumps to using 100% cpu. kill -9 doesn't work, and any other app that tries to use the pcm device locks as well. i have to reboot to fix it. which kernel version are you using? the new code on rc7 simply tries allocation via vmalloc(). if it fails, it means that the system resource is really exhausted. or, there might be memory leak or so... Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [Alsa-user] sb live dma buffer alloc failure?
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 behavionr rc6? i mean the machine stalls, not telling you back the no-memory error. Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
