Re: [Alsa-devel] Clicks in output using intel8x0 driver (and a few questions)
On Thu, 2004-03-18 at 23:03, Josh Green wrote: I have a laptop with the following hardware: P4 3.06Ghz CPU 82801DB AC'97 Audio Controller 82801DB AC'97 Modem Controller nVidia GeForce Go5200 and software: Linux Kernel 2.6.3 (with some ACPI patches) Alsa 1.0.3 Glibc 2.3.2 For the most part the audio works fine, except when doing CPU intensive tasks. When there is a lot of CPU activity the audio will sometimes degrade into a lot of clicks and pops in the output, this can go on for some time and vary in loudness and rate of occurrence and sometimes it sounds like a whole audio fragment is skipped after which it will sometimes go back into sync again. Thought I would reply to my message to mention that I figured out whats causing this problem. Looks like the Intel SpeedStep is doing thermal throttling when there is a lot of CPU activity. Another side effect of this (besides audio degrading to a bunch of clicks) is that games will toggle between running normal speed and then really slow (at about 4 second intervals). I ran a script to monitor changes in /proc/acpi/processor/CPU0/throttling and it confirmed that the throttling state was toggling between T0 and T2 (full speed and 25% throttled respectively). So I suppose this is probably not an ALSA problem, but I'm not sure where the problem is. I turned off speed stepping in the BIOS, which sets the CPU frequency at 1.6Ghz (half speed) and everything runs great. The temperature reported is much lower, games remain normal speed and no more audio problems. So I'm not sure if this means I have defective hardware, Linux is unable to track the speed changes correctly or the cooling policy is throttling the CPU instead of maxing the fan. I now have a cooling platform (3 fans powered by USB) that I set my laptop on top of, which improves things, but the problem still remains. I now have SpeedStep turned off, since the overall system operation is cooler and smoother. Thanks for any information someone might have on this problem, cheers. Josh Green --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Clicks in output using intel8x0 driver (and a few questions)
I have a laptop with the following hardware: P4 3.06Ghz CPU 82801DB AC'97 Audio Controller 82801DB AC'97 Modem Controller nVidia GeForce Go5200 and software: Linux Kernel 2.6.3 (with some ACPI patches) Alsa 1.0.3 Glibc 2.3.2 For the most part the audio works fine, except when doing CPU intensive tasks. When there is a lot of CPU activity the audio will sometimes degrade into a lot of clicks and pops in the output, this can go on for some time and vary in loudness and rate of occurrence and sometimes it sounds like a whole audio fragment is skipped after which it will sometimes go back into sync again. I first noticed this in games, but afterward I noticed it when compiling the kernel or re-encoding a movie in the background but listening to music with XMMS (using OSS emulation). When audio gets bad with XMMS, it is sufficient to pause and play again, in which case it will be back to normal, and then degrade again eventually. While I'm at it, I'll throw a couple of questions out there (hopefully no one minds). I was curious what the state is of the intel8x0m driver, since I have an accursed CH4 82801DB AC'97 Modem Controller which is an HSF Conexant device. I have it working with the linuxant.com drivers, but they are rather unstable with the newer 2.6.4 kernel and contain binary code. Anyone have this working with this modem? My last question pertains to profiling. This laptop tends to have rather large latency stutters at regular intervals (probably between 1 and 2 seconds apart). This is noticeable particularly in games and when playing movies. I ran oprofile but the output isn't too helpful, since it would be nicer to know exactly when a section of code was taking a long time. Anyone know of some good strategies for tracking down latency issues with 2.6 kernels? Thanks in advance for any help :) Cheers! Josh Green --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [linux-audio-dev] Re: Sblive on LAD (was: SBLive again)
On Wed, 2003-05-21 at 11:15, Lukas Degener wrote: Linium wrote: Hi, I saw your request about the crackling noise you get with the sblive card. I have such a beast too, and in the past i had problem with full-duplex at 44.1 khz. The Sblive work internally at 48khz and work very well at this samplerate under Alsa, but at 44.1 khz some noise appeared. May be it is the same problem ? try 48 khz and see if it solves it. Note: i don't know if this issue has been adressed now by the Alsa team, so may be i am writting for nothing... but who know ? :) Linium Just let me say thanks to Linium and others: The problem seems to have disapeared after i made jack use 48khz instead of 44.1khz I have to do some more testing, but it seems i can now drive my apps in full-duplex without major problems. Why the different behaviour of alsa and jack? I guess that was because the app i mainly used for testing (ams) would set the sample rate to 48khz when using alsa and accept the preset rate (44,1khz) when used with jackd. which lead me into the false assumption that there could be something wrong with jack. Glad that's solved! :-) Lukas Cool, thats good to know. I wonder if the ALSA folks know this, CC'ing them just in case they don't. Cheers. Josh Green --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [linux-audio-dev] Re: [Alsa-devel] Audigy1 MIDI input,wavetable support?
On Fri, 2003-03-07 at 15:29, Mark J Roberts wrote: Josh Green: If you want to check these projects out, you can either wait a few days for FluidSynth 1.0 to be released which a release of Swami will follow shortly after, or you can get Swami CVS and FluidSynth CVS. Cheers. Thanks for all the help. Savannah CVS is giving me unexpected EOFs at the moment, so I just tried iiwusynth 0.2.1. I'm very impressed. It worked right out of the box. Do you have support in the works for DLS/Gigastudio format? I'd be thrilled if I could get that working. Actually, yes :) I'm currently working right now with DLS support (like within the last few days). I have put a lot of work into getting the archetecture in place in Swami to support different patch formats. DLS2/Gigastudio is the first other format I am adding (I have not yet researched what additional info is added by Gigastudio, if any). I currently have all the run time objects defined as well as the DLS loader, just haven't tested it yet. This is all with the new Swami branch, which is not quite ready for public consumption. FluidSynth is most likely going to stay SoundFont based, which isn't really a problem, since it has a nice API that allows for other formats to be synthesized (within the scope of a SoundFont of course). If you would like to know when this stuff is available, you could join the swami-devel list (http://lists.sourceforge.net/lists/listinfo/swami-devel) it currently has very little traffic, so no worries there. I'm really excited about where Swami is going, its somewhat of a slow process, but it is definately getting there :) Cheers. Josh Green --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Audigy1 MIDI input, wavetable support?
On Fri, 2003-03-07 at 07:44, Mark J Roberts wrote: I am trying to load a soundfont into my Audigy1's wavetable and play it with a MIDI keyboard. I am using kernel 2.5.64. MIDI output verifiably works. However, MIDI input does not. The cable and keyboard are not the problem--I've tried them with an es1371, and I easily got MIDI input working. My procedure with the Audigy1: cat /dev/snd/midiC0D0 watch /proc/interrupts watch /proc/asound/Audigy/midi0 No interrupts occur and no bytes are read. I have also tried using aconnect to connect the inputs. Does anyone else see this behavior? I've got one more question. What program should I use to configure the wavetable and load the soundfonts? I found a couple versions of awesfx, neither of which was compatible with my ALSA. I know that ALSA contains support for the wavetable of the EMU8k and EMU10k series of cards (AWE 32/64 and Live! respectively). I'm not absolutely sure whether the wavetable on the Audigy is also supported, but chances are it is. The SoundFont loading API is OSS based, but ALSA uses it so awesfx (sfxload utility, etc) should work (provided the API is actually there for the Audigy). I'm convinced that software synthesis is the way to go. It allows for easier routing of the synthesized data (via Jack for example) and supports any sound card. This is the approach I have gone with with Swami (http://swami.sourceforge.net) the successor to the Smurf SoundFont Editor which was based on the OSS awesfx API. Swami uses FluidSynth (http://www.fluid-synth.org - was previously called iiwusynth) to do software synthesis of SoundFont files. Using software synthesis gives us these additional features over current Linux supported hardware solutions: - Modulator support, allowing for real time modulation of effects with MIDI controllers (or with GUI controls from Swami) - Customizable Reverb/Chorus (EMU10k doesn't have support for these effects in Linux) - Routing of audio via Jack, opening up a whole world of audio processing, effects, etc. The downside is of course the CPU usage, so in the future I will likely be re-adding support to Swami for the hardware wavetable OSS API. If you want to check these projects out, you can either wait a few days for FluidSynth 1.0 to be released which a release of Swami will follow shortly after, or you can get Swami CVS and FluidSynth CVS. Cheers. Josh Green --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Broken pipe mystery
On Thu, 2003-02-13 at 12:56, Pete Barnard wrote: : Does it always crash after the same time? No. It didin't crash after the same time. The problem is fixed now thanks to Josh Green's tip. (I wrote a function that caught the EPIPE error and then did a snd_pcm_prepare). I left it for 2 nights with a system(date) in the catch function and got an EPIPE once on one night and not at all on the second night - so even though it is fixed I'm still slightly curious as to why I got this problem/feature at all. Regards, Pete Its due to your program not being able to meet the deadline for writing an audio buffer for playback. This is often Linux kernel related and there is lots of information about tuning your kernel (do a search for linux kernel low latency). It can be somewhat of a black art, because different hardware and Linux drivers can have adverse effects on latency. For instance if your hard disk is IDE and isn't tuned right (DMA not enabled for instance) you can get real long latency spikes when reading/writing the hard disk. You'll also want to look into the lowlat patch and perhaps the preempt patch as well. Kernels that come with Linux distributions have a tendency to not be very low latency friendly, so if you wan't low latency, build your own kernel with one of those patches. On your program side: You can increase the audio buffer size and/or count to minimize underruns (at the cost of higher latency audio playback). If you require low latency, run your program with SCHED_FIFO scheduling (see man sched_setscheduler, requires root privileges). Note that your program then has the ability to lock up the machine, should it decide to consume all the CPU time. I think this is one of the main things that still needs to be solved with Linux and audio. Low latency audio shouldn't entail buggy processes being able to bring the system to its knees. Cheers. Josh Green --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Broken pipe mystery
On Sat, 2003-02-08 at 02:21, Pete Barnard wrote:
I am using ALSA 0.9.0rc7 and Red Hat Linux 7.2. My sound card is a CS461x.
My computer is a reasonably powerful beast with 512M of RAM and 1Gig clock
speed.
I have written a simple capture program which reads interleaved samples from
the sound card and goes around in a continuous while(1) loop. My program
works perfectly - until it crashes after several hours with the message:
read from audio interface failed: broken pipe.
I have narrowed it down to the following piece of code. The size of buf is 256
(shorts). Why would the snd_pcm_readi suddenly (randomly?) fail with a broken pipe???
Any ideas or suggestions would be greatly appreciated as I'm struggling with this
annoying (and difficult to debug) problem.
Regards,
Pete
while (1)
{
if ((err = snd_pcm_readi(capture_handle,buf,128)) != 128
{
// this is where it fails after several hours of working
successfully
cout read from audio interface failed: snd_strerror(err)
endl;
exit(1);
}
}
If I remember correctly the EPIPE error code is returned when an xrun
occurs. In the case of a read it would be a buffer overrun. Your code
should check for this return value and I believe you have to start the
stream again with snd_pcm_prepare. Check out the ALSA site for HOWTOs
and the like. Cheers.
Josh Green
---
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] Edirol PCR-50 keyboard with ALSA USB MIDI
I sent an email to alsa-user about this issue a few days ago, but now I've delved into the problem a little more and believe it to be a bug (rather than user error :) I'm having some troubles getting my Edirol PCR-50 keyboard working via USB with my laptop. I'm using latest CVS of ALSA (as of December 28 2002) and stock linux-2.4.20 on a Mandrake 9.0 system. The keyboard is detected and the snd-usb-audio module hotplugs itself, but I'm not getting any data via the raw MIDI port or sequencer ports. Here is the output from /var/log/messages when plugging the device: Dec 29 19:39:44 SillyPuddy kernel: hub.c: new USB device 00:07.2-1.3, assigned address 4 Dec 29 19:39:44 SillyPuddy kernel: usb.c: USB device 4 (vend/prod 0x582/0x33) is not claimed by any active driver. Dec 29 19:39:47 SillyPuddy /etc/hotplug/usb.agent: Setup snd-usb-audio for USB product 582/33/100 Dec 29 19:39:47 SillyPuddy kernel: usb.c: registered new driver snd-usb-audio Dec 29 19:39:47 SillyPuddy kernel: snd-usb-midi: created 2 output and 3 input ports Dec 29 19:39:47 SillyPuddy kernel: usb-uhci.c: uhci_submit_urb: pipesize for pipe 40008480 is zero Dec 29 19:39:47 SillyPuddy kernel: snd-usb-midi: usb_submit_urb: -90 The last 2 log lines I believe are significant. Looking at the code I found that the usb_maxpacket macro is returning 0 for the input endpoint for the PCR USB device which causes uhci_submit_urb to fail (-90 = EMSGSIZE which probably isn't really the right code, EINVAL maybe). I couldn't figure out if this size was set by ALSA or supplied by the device info or something, and since its a bit over my head, I decided to post this here. I hope someone has a better idea of whats going on. Some more info: /proc/asound/cards: 0 [PCR]: USB-Audio - EDIROL PCR Roland EDIROL PCR cat /proc/asound/PCR/midi0: Roland EDIROL PCR Output 0 Tx bytes : 0 Output 1 Tx bytes : 0 Input 0 Rx bytes : 0 Input 1 Rx bytes : 0 Input 2 Rx bytes : 0 I've also attached lsusb -v output. Cheers. Josh Green Bus 001 Device 001: ID : Bus 001 Device 002: ID 05e3:0604 Genesys Logic, Inc. Bus 001 Device 006: ID 0582:0033 Roland Corp.
[Alsa-devel] mixer problem with ymfpci
I'm currently have a problem setting mixer controls with alsactl and the ymfpci driver (Yamaha YMF-744B on a laptop). This problem started with alsa 0.9.0beta12 and is present in rc1 as well. I've removed the /etc/asound.state file and did a `alsactl store' which has no problems. `alsactl restore' on the other hand gives me the following message: alsactl: set_control:876: Cannot write control '0,0,0,,0': Invalid argument Although it does restore all the control settings, it fails to restore my mixer settings on boot. /etc/rc.d/init.d/alsa is part of initscripts on Mandrake 8.1. I haven't quite figured out why it doesn't but that also started with beta12 so I suspect its the same problem. Cheers! Josh Green P.S. Nice job on the web site. The documentation section is more complete now. I notice that the Documentation and API page both contain the same content. Seems like it might make sense just to merge all of it into one page. Then have a heading for User Documentation and Developer Documentation or something. ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] [Fwd: mixer problem with ymfpci]
I sent this email before without realizing I wasn't a member of the list (I am now), it appears to be stuck in the moderation loop :) So I'm sending it again, please excuse a double posting, thanks. Josh Green ---BeginMessage--- I'm currently have a problem setting mixer controls with alsactl and the ymfpci driver (Yamaha YMF-744B on a laptop). This problem started with alsa 0.9.0beta12 and is present in rc1 as well. I've removed the /etc/asound.state file and did a `alsactl store' which has no problems. `alsactl restore' on the other hand gives me the following message: alsactl: set_control:876: Cannot write control '0,0,0,,0': Invalid argument Although it does restore all the control settings, it fails to restore my mixer settings on boot. /etc/rc.d/init.d/alsa is part of initscripts on Mandrake 8.1. I haven't quite figured out why it doesn't but that also started with beta12 so I suspect its the same problem. Cheers! Josh Green P.S. Nice job on the web site. The documentation section is more complete now. I notice that the Documentation and API page both contain the same content. Seems like it might make sense just to merge all of it into one page. Then have a heading for User Documentation and Developer Documentation or something. ---End Message---
[Alsa-devel] Re: [linux-audio-dev] ALSA homepage redesign
On Wed, 2002-04-17 at 23:00, Patrick Shirkey wrote: I have now migrated the new ALSA homepage. It was redesigned to be more user friendly. http://www.alsa-project.org Looking good, and its nice to know someone is working on it. I noticed that the documentation doesn't have the Doxygen generated API reference for ALSA lib though. In fact I can no longer find it on the web site. I like many of the other suggestions about taking down the older docs to lesson the confusion factor as well. I will now add new links to the native applications page. So far I have: jack Ardour TiMidity Glame PD Rosengarden MusE Are these correct and are there any others? If you are counting ALSA sequencer support than the Smurf Sound Font Editor could be added. Perhaps there should be a designation of what kind of support the program provides (sequencer and/or PCM), maybe.. iiwusynth could also be added. Cheers! Josh Green ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] card-serial and midiator MS-101 serial interface
On Mon, 2002-01-14 at 17:48, DeMeo, William wrote: Hi Josh, You might want to check out Midiman's Portman PC/S, since there are now drivers at: http://sourceforge.net/projects/portmanlinux/ I have one of these and tried to get it working about 1 year ago with Linux _without_ success. But I have yet to try it with Oliv's driver. He says it's working fine now, so I plan to try again at some point... The Portman's a pretty inexpensive option. On the other hand, it seems the Mediator has been working with Linux for quite a while, so that might be a safer bet. Good luck, and let me know if you get something working. William It looks like a nice device but my impression is that it is OSS only. It probably wouldn't be that hard to port a driver from OSS to ALSA (especially since there is already an ALSA serial driver available) so it could be an option. Thanks for the tip. I'll be sure to let you know when I get something working. Lates.. -- Josh Green ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] card-serial and midiator MS-101 serial interface
I've been seeing talk of ALSA support for serial interfaces lately, and have found myself searching for it as well. I have a laptop that I would like to add MIDI support to, I only need 1 input (output not really necessary, just want to connect a keyboard). I searched through the archives (with google of course, as geocrawler is severely broken) and found some posts on using the Mediator MS-124W. I found the driver in the ALSA source and noticed that only the MS-124W and 124T are supported currently. Since I don't need anything fancy, the MS-124W is a bit overkill and a lot more pricey as well ($100 more than the MS-101). Someone documented in the driver that they had documentation on the other models but no units to test with. If I bought the MS-101, would it be possible to get this information, and how different is it than the MS-124W (to gauge how hard a driver implementation would be). An alternative to this would be to use a USB MIDI interface, but AFAIK ALSA doesn't support this yet, which is useless to me. Any ideas of when this will happen and how much work would be involved. Thanks. Please CC as I'm not on the list anymore (going traveling soon). P.S. I BCC'd the driver author (determined from source), I'll understand if he is too busy to respond :) -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Kernel oops with via686a driver
Hmm, I sent this message before, but it hasn't gotten to the list yet. I think it was the email client I was using. Please disregard if it is sent twice. -- I finally got around to trying that via686a sound device again with ALSA. I tried ALSA v0.9.0beta10 with Kernel 2.4.13. When running XMMS in OSS mode I got an oops immediately after playing an MP3. I've attached the output from ksymoops. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ksymoops 2.4.1 on i686 2.4.13. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.13/ (default) -m /boot/System.map-2.4.13 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Dec 22 21:22:46 meanbox kernel: Unable to handle kernel paging request at virtual address d48a Dec 22 21:22:46 meanbox kernel: d0858350 Dec 22 21:22:46 meanbox kernel: *pde = 0c506067 Dec 22 21:22:46 meanbox kernel: Oops: Dec 22 21:22:46 meanbox kernel: CPU:0 Dec 22 21:22:46 meanbox kernel: EIP:0010:[d0858350]Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Dec 22 21:22:46 meanbox kernel: EFLAGS: 00210283 Dec 22 21:22:46 meanbox kernel: eax: 7fff ebx: 343049d5 ecx: 44a6 edx: 4731 Dec 22 21:22:46 meanbox kernel: esi: d48a edi: 00d5 ebp: 4731 esp: caf7fe84 Dec 22 21:22:46 meanbox kernel: ds: 0018 es: 0018 ss: 0018 Dec 22 21:22:46 meanbox kernel: Process xmms (pid: 1110, stackpage=caf7f000) Dec 22 21:22:46 meanbox kernel: Stack: d08582f1 d0858384 d0858038 cf61a14c cf61a130 0001 0004 Dec 22 21:22:46 meanbox kernel:0004 d489d164 44a649d5 03ee 045a 0400 cf61a0c0 Dec 22 21:22:46 meanbox kernel:cf30eec0 d085899a cf61a0c0 cbd5fdc0 cbd5fd80 03ff 045a cf61a0c0 Dec 22 21:22:46 meanbox kernel: Call Trace: [d08582f1] [d0858384] [d0858038] [d085899a] [d0855774] Dec 22 21:22:46 meanbox kernel:[d0851e91] [d0852013] [d0853cb3] [sys_write+149/208] [sys_ioctl+386/400] [system_call+51/56] Dec 22 21:22:46 meanbox kernel:[d0851e91] [d0852013] [d0853cb3] [c012e2f5] [c0139de2] [c0106cdf] Dec 22 21:22:46 meanbox kernel: Code: 0f b7 16 0f b6 3e 8b 1e 89 d0 ff 64 24 04 89 f6 8b 54 24 28 EIP; d0858350 [snd-pcm-oss]resample_expand+3b0/520 = Trace; d08582f1 [snd-pcm-oss]resample_expand+351/520 Trace; d0858384 [snd-pcm-oss]resample_expand+3e4/520 Trace; d0858038 [snd-pcm-oss]resample_expand+98/520 Trace; d085899a [snd-pcm-oss]rate_transfer+2a/40 Trace; d0855774 [snd-pcm-oss]snd_pcm_plug_write_transfer+94/c0 Trace; d0851e91 [snd-pcm-oss]snd_pcm_oss_write2+81/d0 Trace; d0852013 [snd-pcm-oss]snd_pcm_oss_write1+133/160 Trace; d0853cb3 [snd-pcm-oss]snd_pcm_oss_write+33/50 Trace; d0851e91 [snd-pcm-oss]snd_pcm_oss_write2+81/d0 Trace; d0852013 [snd-pcm-oss]snd_pcm_oss_write1+133/160 Trace; d0853cb3 [snd-pcm-oss]snd_pcm_oss_write+33/50 Trace; c012e2f5 sys_write+95/d0 Trace; c0139de2 sys_ioctl+182/190 Trace; c0106cdf system_call+33/38 Code; d0858350 [snd-pcm-oss]resample_expand+3b0/520 _EIP: Code; d0858350 [snd-pcm-oss]resample_expand+3b0/520 = 0: 0f b7 16 movzwl (%esi),%edx = Code; d0858353 [snd-pcm-oss]resample_expand+3b3/520 3: 0f b6 3e movzbl (%esi),%edi Code; d0858356 [snd-pcm-oss]resample_expand+3b6/520 6: 8b 1e mov(%esi),%ebx Code; d0858358 [snd-pcm-oss]resample_expand+3b8/520 8: 89 d0 mov%edx,%eax Code; d085835a [snd-pcm-oss]resample_expand+3ba/520 a: ff 64 24 04 jmp*0x4(%esp,1) Code; d085835e [snd-pcm-oss]resample_expand+3be/520 e: 89 f6 mov%esi,%esi Code; d0858360 [snd-pcm-oss]resample_expand+3c0/520 10: 8b 54 24 28 mov0x28(%esp,1),%edx 1 warning issued. Results may not be reliable.
Re: [Alsa-devel] The problem with VIA686B/8231/8233 with Mandrake8.1
On Mon, 2001-12-17 at 23:25, Karen Liu wrote: Hi all, I have a problem with Mandrake 8.1. When I configure the ALSA driver on VIA686B, 8231 and 8233 with Mandrake 8.1, there is an erroe message --The ALSA sound driver was not detected in this system. I have already finished all installing process and run all necessary command by the user guide. The sound device is ok. I don't know what's wrong with them. Is there any solution or suggestion? Thank you very much!! Karen I've had this same problem. I haven't tried the latest driver yet though (its on somebody else's system). Anybody else have a VIA686B that works or doesn't work? -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] snd_ctl_open mode
On Mon, 2001-12-17 at 04:32, Vladimir Dergachev wrote: At least thats what the doxygen generated API documentation says. You can browse it online. If you didn't already know about it its at: http://www.alsa-project.org/alsa-doc/alsa-lib/ Its linked off the ALSA documentation page (not the API one for SOME reason :) I did look at it.. Is there something I am missing ? It only has PCM (digital audio) interface and Configuration - nothing about plain snd_ctl and snd_hctl or mixer. Vladimir Dergachev He he.. Sounds like you're overlooking the guts of the doxygen documentation :) Click the Modules link at the top. That should give you a better idea. The PCM (digital audio) interface is more of a nice general overview description, Modules will give you access to all the reference stuff. I wonder how many other people make this mistake? It seems sad that someone would think that that is the only documentation, when pretty much every function in ALSA has at least a brief blurb about it (whether that blurb is useful information is another story). I still think the access to this doxygen information is a little bit confusing (at least when browsing online). Why isn't it on the API page? Perhaps we should start considering the ALSA 0.9.0 stuff to be the current release? It seems like its still being considered cutting edge although it is much improved compared to 0.5.0. Much of the more prominent documentation listed is fairly outdated. Seems like those pages need to be re-worked to have the new 0.9.0 stuff as the prominent links and the old stuff linked only for its historical value. Many people keep complaining about there not being that much documentation. Seems to me like there is fairly sufficient reference documentation, although we still suffer from more general overview docs. Perhaps they don't know about the doxygen stuff, and this would quite some complaints? -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Full duplex working with SB Live!
Yes! I finally got full duplex flawlessly working on my SB Live. It appears that it was the full duplex test program I've been using. There were 2 problems: 1. I decided to modify what Jaroslav had sent me by polling separately on the input and output descriptors in the order that was expected. This caused missed overruns and things to just generally be wrong. 2. For some reason enforcing the order in which read/writes are done from the input/output (accomplished by an integer that toggled between 0 and 1) caused the input stream available size to slowly increase. I'm not sure why #2 is the case, but by processing the input and output when they are available (rather than ensuring the processing order) everything stays synced. The results are a vast improvement over the previous tests I did. Some stress testing still causes some buzzing and clicks to be heard though. Since I'm running both streams in NONBLOCK mode I'm curious when the initial write of 2 fragments of data to the output returns. Does it return immediately, after 1 fragment is written or after 2 fragments? This would determine where the playback and record pointers are in reference to each other (if they share the same buffer). I'll attach the current code for the full duplex test program I used. Its not very general at the moment perhaps a real full-duplex test program should be written for distributing with ALSA? For detailed information uncomment the #define HISTORY 1 which fills up a history buffer until it gets to a certain size and then exits and displays the results, piping through less is a good idea :) -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Full duplex working with SB Live!
On Fri, 2001-12-14 at 02:33, Josh Green wrote:
I'll attach the current code for the full duplex test program I used.
Its not very general at the moment perhaps a real full-duplex test
program should be written for distributing with ALSA?
For detailed information uncomment the #define HISTORY 1 which fills
up a history buffer until it gets to a certain size and then exits and
displays the results, piping through less is a good idea :)
Ooops! Forgot the attachment. Here you go for anyone who missed it.
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
/*
Full duplex ALSA test program
Do whatever you want with it and use it at your own risk
Josh Green [EMAIL PROTECTED]
Fixes by Jaroslav Kysela
November 28, 2001
*/
#include stdio.h
#include alsa/asoundlib.h
#include string.h
#include sched.h
#define PERIOD_SIZE 384
#define BUFFER_SIZE PERIOD_SIZE * 2
#define CHANNELS 2
#define RATE 44100
/* uncomment for history logging (available data on each read/write and XRUNs)
probably want to pipe through less though, runs until the history gets to
a fixed length (HISTORY_SIZE entries) then quits and prints history */
#define HISTORY 1
#define HISTORY_SIZE 12000
#define OK 0
#define FAIL 1
#define TRUE 1
#define FALSE 0
char *audiobuf = NULL;
int audiobuf_bytes = 0;
snd_pcm_t *cards[2] = { NULL };
int fdcount = 0;
struct pollfd *ufds = NULL;
#ifdef HISTORY
unsigned int history[HISTORY_SIZE];
int histndx = 0;
#endif
int
setup_device (int index, char *device, int play)
{
int err;
snd_pcm_t *handle;
snd_pcm_hw_params_t *params; /* Hardware parameters */
snd_pcm_sw_params_t *swparams; /* Software parameters */
int thisbuf_bytes; /* this cards audio buffer size */
unsigned int rate;
snd_pcm_uframes_t start_threshold, stop_threshold;
/* Open output sound card */
if (err = snd_pcm_open (handle, device,
play ? SND_PCM_STREAM_PLAYBACK : SND_PCM_STREAM_CAPTURE,
SND_PCM_NONBLOCK) 0)
{
fprintf (stderr, snd_pcm_open failed: %s\n, snd_strerror (err));
return (FAIL);
}
cards[index] = handle;
snd_pcm_hw_params_alloca (params);
snd_pcm_sw_params_alloca (swparams);
snd_pcm_hw_params_any (handle, params);
snd_pcm_hw_params_set_access(handle, params,
SND_PCM_ACCESS_RW_INTERLEAVED);
snd_pcm_hw_params_set_format (handle, params,
SND_PCM_FORMAT_S16_LE);
snd_pcm_hw_params_set_channels (handle, params, CHANNELS);
rate = snd_pcm_hw_params_set_rate_near (handle, params, RATE, 0);
if (snd_pcm_hw_params_set_period_size (handle, params, PERIOD_SIZE, 0) 0)
{
fprintf (stderr, Failed to set period size!\n);
return (FAIL);
}
if (snd_pcm_hw_params_set_buffer_size (handle, params, BUFFER_SIZE) 0)
{
fprintf (stderr, Failed to set buffer size!\n);
return (FAIL);
}
err = snd_pcm_hw_params (handle, params);
/* set software parameters */
snd_pcm_sw_params_current (handle, swparams);
snd_pcm_sw_params_set_sleep_min (handle, swparams, 0);
start_threshold = 0x7fff;
snd_pcm_sw_params_set_start_threshold(handle, swparams, start_threshold);
stop_threshold = BUFFER_SIZE;
snd_pcm_sw_params_set_stop_threshold(handle, swparams, stop_threshold);
snd_pcm_sw_params (handle, swparams);
/* Prepare our buffer */
thisbuf_bytes = BUFFER_SIZE * (16 / 8) * CHANNELS;
if (audiobuf_bytes == 0)
{
audiobuf = malloc (thisbuf_bytes);
audiobuf_bytes = thisbuf_bytes;
}
else if (audiobuf_bytes != thisbuf_bytes)
{
fprintf (stderr, audio buffers not same size (%d != %d)!\n,
audiobuf_bytes, thisbuf_bytes);
return (FAIL);
}
return (OK);
}
void
setup_pollfds (void)
{
int count1, count2;
count1 = snd_pcm_poll_descriptors_count (cards[0]);
count2 = snd_pcm_poll_descriptors_count (cards[1]);
fdcount = count1 + count2;
ufds = malloc (sizeof (struct pollfd) * (count1 + count2));
snd_pcm_poll_descriptors (cards[0], ufds, count1);
snd_pcm_poll_descriptors (cards[1], ufds + count1, count2);
}
void
xrun_recovery()
{
int err;
fprintf(stderr, XRUN recovery\n);
if (err = snd_pcm_prepare(cards[0]) 0) {
fprintf (stderr, Failed to prepare devices\n);
exit (1);
}
if (err = snd_pcm_writei (cards[0], audiobuf, PERIOD_SIZE * 2) 0) {
fprintf (stderr, Failed to write initial bytes\n);
exit (1);
}
fprintf (stderr, Wrote %d start bytes\n, err);
snd_pcm_start(cards[1]);
}
int
main (void)
{
int i, r, f, avail;
short revents;
int err;
struct sched_param schp;
snd_pcm_t *handle;
snd_pcm_status_t *status;
snd_pcm_state_t state;
char *s;
memset (schp, 0, sizeof (schp));
schp.sched_priority = sched_get_priority_max (SCHED_FIFO);
if (sched_setscheduler (0, SCHED_FIFO, schp) != 0)
fprintf (stderr, Failed to run SCHED_FIFO\n);
/* Open output sound card */
if (setup_device (0, plughw:0,0, TRUE) != OK)
{
fprintf
Re: [Alsa-devel] something strange in ALSA
On Sun, 2001-12-02 at 14:21, Christophe Baillon wrote: Hi, I have modified an example programm of the alsa website, in fact to test reading a wave file. The behaviour of my program is very strange ! It works fine, the sample is played until the end, except when I change virtual screen in Window Maker !! When i do it, the program exit without error before the end of the sample. Very strange Is there something wrong in the program ? This is the source code : Sounds like you aren't handling xruns (buffer underruns in this case). There are some software parameters for controlling what happens when an xrun occurs. snd_pcm_sw_params_set_stop_threshold PCM is automatically stopped in SND_PCM_STATE_XRUN state when available frames is = threshold snd_pcm_sw_params_set_silence_threshold A portion of playback buffer is overwritten with silence (see snd_pcm_sw_params_set_silence_size) when playback underrun is nearer than silence threshold I'm not really sure how to use these myself. But you either want to handle the XRUN (which is what I have normally done) or make it so it never stops (set stop_threshold really high 0x, or something) and the silence parameters correctly so that silence will be sent rather than looping part of the buffer again. I might be wrong about all this, so someone who really knows about ALSA XRUN handling should then step in :) -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Inappropriate ioctl for device
On Sat, 2001-12-01 at 18:18, Christophe Baillon wrote: Hi I try to compile several examples of programms using alsa, found on the alsa's website, but i have got always a message like : ALSA lib pcm_hw.c:598:(snd_pcm_hw_open) SNDRV_PCM_IOCTL_PVERSION failed: Inappropriate ioctl for device Error opening hw:0,0 alsa version is 0.9.0beta9, and kernel 2.4.16 This is fixed in ALSA CVS (and probably 0.9.0beta10 ??, as it was just released). Apparently some things got changed with 2.4.14+ (I gather from the release announcement on the main page on http://www.alsa-project.org). -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Question on snd_pcm_open and sb live
On Fri, 2001-11-30 at 02:06, Alexander Ehlert wrote: Hi, I have the following code in glame's alsa_audio_out plugin: char *pcm_name=plughw:0,0; ... err = snd_pcm_open(handle, pcm_name, SND_PCM_STREAM_PLAYBACK, SND_PCM_NONBLOCK); if (err0) FILTER_ERROR_RETURN(couldn't open audio device); /* set back to blocking io */ snd_pcm_nonblock(handle, 0); Now this works with a lot of cards, but strangely it doesn't work with the SB Live. I always get err=-22. But what the heck is -22 ? I grepped through the include files, but I couldn't find anything. Any ideas whats going wrong? BTW: The Alsa Lib has a strange way of error handling. Either it just quits your whole application with asserts or if you turn the asserts off it segfaults. Cheers, Alex -- It kind of slipped my mind, but I just fixed the ALSA 0.9.0betas related problems with GLAME just yesterday. The problem with input dieing after an overrun as well as cleaning up some of the parameter setting code. I guess I didn't mention it because I was in the middle of adding a full duplex plugin (actually just another routine in the alsa driver file). I need to make a patch for the changes I made, which I will do as soon as possible. Right now I should go to sleep though. I have an SB Live! and it works fine BTW. If you want to figure out what an error is use snd_strerror. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problem with snd 5.5 and cs46xx
On Wed, 2001-11-28 at 18:36, A Grant wrote: I'm interested in getting snd up and working and have compiled it with alsa support. I have a Turtle Beach Santa Cruz using 2.4.16 and cs46xx beta9 drivers and libs. Here's the prob: :~$ snd ALSA lib pcm_hw.c:598:(snd_pcm_hw_open) SNDRV_PCM_IOCTL_PVERSION failed: Inappropriate ioctl for device alsa_get_hardware_params: open pcm hw:0,0 for stream 0: Inappropriate ioctl for deviceALSA lib pcm_hw.c:598:(snd_pcm_hw_open) SNDRV_PCM_IOCTL_PVERSION failed: Inappropriate ioctl for device alsa_get_hardware_params: open pcm hw:0,0 for stream 1: Inappropriate ioctl for devicecalled from snd(show_stack+0x17) [0x80a066f] snd(snd_doit+0x9a3) [0x8137b53] snd(g_init_mix+0x168d) [0x80fb94d] /usr/lib/libguile.so.9(scm_boot_guile+0x390) [0x4005c098] /usr/lib/libguile.so.9(scm_internal_lazy_catch+0x9b) [0x40080073] /usr/lib/libguile.so.9(scm_boot_guile+0x33e) [0x4005c046] /usr/lib/libguile.so.9(scm_boot_guile+0x3c) [0x4005bd44] snd(main+0x18) [0x80fb970] /lib/libc.so.6(__libc_start_main+0xbb) [0x403d94cf] snd(_start+0x21) [0x8062171] :~$ ideas!? TIA andy Yeah, I think it was mentioned (on alsa-devel) that this is fixed in ALSA CVS? New kernel ioctls changed so you'll need to check out CVS to get it working. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] kernel 2.5.0
On Tue, 2001-11-27 at 00:32, Jaroslav Kysela wrote: On Mon, 26 Nov 2001, Dan Hollis wrote: Now that kernel 2.5.0 tree is started, shouldn't we start pushing to get ALSA into the tree? Let's go. Our latest patch against 2.5.0 is: ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-0.9.0beta9-k2.5.0-3310916.diff.bz2 The oss-move script (to change the directory structure) can be found at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa/alsa-driver/utils/oss-move If nobody has comments, I'm ready to prepare a whole patch for Linus against the actual 2.5.1pre code. Jaroslav I have some comments.. Wooohooo! Yeah! Cool! -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Latencytest results
On Sun, 2001-11-25 at 22:14, Tom Browne wrote: Just stuck them online. Don't know what's going on with the big white block in the X11 test... is gd writing to offscreen VRAM or something? http://www.tbrowne.demon.co.uk/latencytest These were taken with the standard Mandrake 8.1 kernel... 2.4.8... no patches applied. Parameters were as default for the run_xxx_test scripts, but with 3 buffers. Note that I had to modify the ALSA open code to get it working with the Envy24... fails with a PCM write error #14 if try to use the device hw:0,0... needed to change it to plughw:0,0... why?!? Machine spec... 1.2GHz Celeron-II running at 1.5GHz ASUS TUSL2-M motheboard (i815EPB) 512MB RAM Seagate Barracuda IV (UDMA5) Savage4 32MB AGP, XFree86 4.1.0 Results were pretty awful to say the least - Linux is doing too much read ahead buffering, and too much write-latering... If there's an LL+buffer patch for 2.4.15 final, I'll give that a go... - Tom. Yuck. Those look pretty bad. What kind of video card do you have? Is DMA enabled on your hard disk? (hdparm) -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [linux-audio-dev] latencytest results webpage
On Tue, 2001-11-20 at 00:14, dave willis wrote:
[heavily edited out list]
these need to all be automatically figured by the software.
Yes, most of them would be.
KernelPatches List of patches applied (PE, LL, AA, etc)
this will only work (automatically) if people make sure that EXTRAVERSION
is properly defined in their kernel Makefile (i had to do some by hand
as not all patches contain this).
I would think this would probably be manual selection lists in a web
form. Perhaps the best way to do this would be to run the latency test
script which would obtain as much info as possible. This data could then
be uploaded. Any fields that could not be determined automatically could
then be filled in manually.
don't forget hdparm settings!
Yeah, I didn't.
IDEParmsIDE hard disk parameters (example: -d 1 -c 1)
-dave
--
perl -e'@email=split(//,.tenmhd\@nosbud);foreach$letter(@email){$
email=$letter.$email;}$email=~s/(m|net\.)/a\1\1/g;print$email\n;'
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [linux-audio-dev] latencytest results webpage
On Fri, 2001-11-16 at 05:28, Andre Pang wrote: On Fri, Nov 16, 2001 at 10:26:23AM +0100, Maarten de Boer wrote: I am thinking of setting up a webpage, where people can post their latencytest results, so we can keep an inventory of the several combinations, categorising on: This is a great idea. I actually started re-writing the latency testing harness scripts because I thought they were too inflexible, and I'm almost finished with the re-write. The idea is to include as much system information as possible in the results , such as kernel version, processor, SMP, VM parameters, as well as making it easy to add new tests to the testing suite. (Think 'download new file and drop in directory' easy). I'll write the list when the new testing suite is ready for release. I'm also interested in an online Linux latency database and have written about it before (not sure which list). It would be nice if the latencytest program could generate machine parse-able system info files that could be easily uploaded to a web form. This web form could also contain questions that can't be automatically determined (kernel patches, name and email address of submitter, etc). Perhaps the .config file from kernel compiles could also be uploaded. Seems like a database like this would grow quite large so it would be nice to start it off organized. A database like this would really help users figure out what to get for a new system and help Linux developers figure out problem drivers. As far as the graphs, perhaps raw floating point data (to conserve space) could be written for each test, that could be rendered into an image on the fly on the web. This would also enable complex latency data analysis, perhaps thats overboard though :) Lets start a list of fields in the database (tab delimited in email): NameName of person submitting results Email Email address DateDate of submission TestVersion Latencytest version TestFrags # of audio fragments during test TestFragSizeSize of each audio fragment TestFileSizeSize of file for disk tests TestListList of tests performed (example: X, proc, write, read, copy) KernelVersion Kernel version tested KernelPatches List of patches applied (PE, LL, AA, etc) KernelCCKernel compiler string (example: gcc-2.96) KernelCPU CPU kernel compiled for (386, Pentium, PIII, etc) FileSystem File system type for disk tests (ext2, reiserfs, etc) IDEParmsIDE hard disk parameters (example: -d 1 -c 1) XWinVersion X windows version SoundDriver Sound driver (OSS/ALSA) SoundVersionVersion of sound driver VideoDriver Video driver string (NVIDIA-1.0-1541, X, etc) MBoardVendorMother board vendor (ASUS, Intel, etc) MBoardModel Mother board model string MBoardChipset Mother board chipset vendor and model (VIA, Intel, AMD, etc) CPUCount# of CPUs in system CPUType Type of CPU (x86, PPC, etc) CPUVendor CPU vendor (AMD, Intel, Motorola, etc) CPUModelNamemodel name field in /proc/cpuinfo CPUMHz cpu MHz field in /proc/cpuinfo RAMSize Amount of memory (in megabytes) HDType Type of hard disk for disk tests (IDE/SCSI) HDModel Hard disk vendor/model string VideoVendor Video card vendor (nvidia, trident, ati, etc) VideoModel Video card model SoundVendor Sound card vendor (Creative, Trident, etc) SoundModel Sound card model string Custom1Type Type of custom hardware (NIC, SCSI card, etc) Custom1ModelModel and vendor string of custom hardware Custom2Type Type of custom hardware (NIC, SCSI card, etc) Custom2ModelModel and vendor string of custom hardware Custom3Type Type of custom hardware (NIC, SCSI card, etc) Custom3ModelModel and vendor string of custom hardware Did I forget anything? Something wrong with my thinking? My preferred web development platform is probably PHP/MySQL. I probably have some time to work on something like this so lets start discussing details :) Would be nice to have a list to discuss this project, should we just use one of the existing lists (linux-audio-dev?) Perhaps starting a sourceforge project would give us a nice place to develop this thing. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [linux-audio-user] Soundcard supporting severalaudio streams
Patrick Shirkey wrote: Abramo Bagnara wrote: SuSE support was invaluable, its lack for so many months has made everything harder and slower for ALSA. That is very good news :) Is it?? My understanding from what Abramo said was that SuSE support used to be available, but now isn't. Is there currently no funding for the ALSA project? If so, have any efforts been made to re-instate funding? I would not know the state of ALSA funding, if it weren't for mentions of it on this email list. Perhaps if more companies knew about this state, they would contribute. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [linux-audio-dev] Re: minimum tick time
On Wed, 2001-11-07 at 19:27, Paul Davis wrote: Ah, OK. yes, i suppose this might not be clear. when you set the size of a period in ALSA, you are basically setting the interval at which the h/w will interrupt the host system to notify it that space/data is available. so, if you set it for 128 frames at 48kHz, when the h/w will interrupt us every 2.3msec. ... Rest of nice description clipped Thanks for that explanation, clarifies a lot for me. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: minimum tick time
On Thu, 2001-11-08 at 01:52, Jaroslav Kysela wrote: On Thu, 8 Nov 2001, Maarten de Boer wrote: Paul Davis wrote: Ah, OK. yes, i suppose this might not be clear. [...] But you made it completely clear now! Thank you very much, Paul. Paul Davis wrote also: but its basically fairly easy to get this performance out of any program that is engineered properly. latency.c is not the correct place to start such a program from, however. its a test tool, not a viable application. And this is the source of all problems: I thought it was a good idea to use latency.c as a starting point. It would be nice if there would be a small low latency i/o with some processing (yes, that would be a more appropriate place for the filtersweep, wouldn't it?) example in the alsa-lib/test. I don't agree with Paul that the latency.c test program is not a good example for testing and showing the capture - process - play circle required by some applications. It's very simple command-line application, easy extensible, now showing also the standard poll/read/write scheme. Anyway, all problems (for poll mechanism) seem to be in the Linux scheduler / wrong drivers or VM manager / mentioned many times by me and until all these time gaps (from the view of a RT task) will not be solved, we can't do this audio processing in a reliable way without having at least two CPUs. Jaroslav Having the latency.c test program take up 100% CPU doesn't seem all that friendly though, or desirable for duplication in another application. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [linux-audio-dev] Re: minimum tick time
On Wed, 2001-11-07 at 08:55, Paul Davis wrote:
I don't think so, but I am probably completely missing the point.
Let's start all over. I have a patched kernel, and I want to have
low latency. I use latest alsa (cvs), and I run the latency test.
(As you might have noticed, I submitted an filtersweep effect for
the latency test, which Jaroslav added to the CVS. Try it with -e)
if i may so, this is absurd :)
- if I run in nonblock mode, it eats all CPU. Latency is excellent,
but it would be nice if I could do something else in the meantime,
for example run a GUI.
$ latency -m 128 -M 128
- if I run in block mode, i get XRUNs, even with larger bufsize
$ latency -e -b -m 256 -M 256
- if I run in poll mode, idem
$ latency -e -b -m 256 -M 256 -p
Is this expected behaviour?
i don't know if its properly written to measure these things at low
latency settings. i don't have the recent source code for this, but
the version i have doesn't have poll mode in it. the program isn't
meant to test low latency, its meant to test round-trip latency,
which is related, but not the same.
all i can tell you is that, as you probably know by know, my apps run
just fine with latency settings down as low as period_frames = 64 at
48kHz (about 1.3msec per interrupt). admittedly, thats on a dual CPU
system. but its basically fairly easy to get this performance out of
any program that is engineered properly. latency.c is not the correct
place to start such a program from, however. its a test tool, not a
viable application.
what are you trying to do?
--p
I think I know the source of Maarten's question. In the
alsa-lib/test/latency.c the readbuf routine has the following code:
do {
r = snd_pcm_readi(handle, buf, len);
} while (r == -EAGAIN);
For the non-blocking case this would take up 100% of the CPU time. I
wrote about this before on the alsa-devel list. Since its running in
SCHED_RR it tends to not let anything else run while it does (i.e.
machine freezes, except for sound output). So I believe the question
Maarten is asking, is how do I program a low latency audio application
without hogging the CPU. I think the answer is poll. The reason I
believe he was asking about increasing the system timer interval, is the
assumption was that poll was limited to the interval of the system
timer. I don't believe this is the case though, but to be honest don't
really know how an application would get scheduled to wake up once ALSA
is ready to send/receive a chunk of audio.
Maarten, please let me know if my assumptions are wrong, I wouldn't want
to put words in your mouth :)
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Weired sounds with SB Live and different motherboard
I just changed the motherboard in my computer from a K6-2 550 with VIA Apollo chipset to a P3 533 with Apollo MVP3/Pro133x chipset. I'm now experiencing a chirping sound in audio playback and other artifacts. It seems to be directly related to IDE hard disk access. I did a test write like so head -c 1 /dev/zero test.dat to write 100 MB of zero data to a file. The chirping sound completely took over the audio sound and my MP3 playing in the background was no longer distinguishable until the write was done. Has anybody else experienced this problem or have any ideas of what could cause it. I'm using ALSA CVS as of a week ago IIRC. Another unrelated problem is with another computer that has a via686a based sound card built on the motherboard. ALSA 0.5.10 seems to work fine. I tried 0.9.0beta8a and the card will no longer initialize correctly. The modules will load, but looking at /proc/asound/cards reports that there are no cards available, and trying to use any devices with it will say the same. Anyone else have a via686a? Any ideas on this one? Thanks in advance to anyone who has some info or solutions to fixing these problems. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Weired sounds with SB Live and differentmotherboard
On Sat, 2001-11-03 at 21:53, Josh Green wrote: I just changed the motherboard in my computer from a K6-2 550 with VIA Apollo chipset to a P3 533 with Apollo MVP3/Pro133x chipset. I'm now experiencing a chirping sound in audio playback and other artifacts. It seems to be directly related to IDE hard disk access. I did a test write like so head -c 1 /dev/zero test.dat to write 100 MB of zero data to a file. The chirping sound completely took over the audio sound and my MP3 playing in the background was no longer distinguishable until the write was done. Has anybody else experienced this problem or have any ideas of what could cause it. I'm using ALSA CVS as of a week ago IIRC. Just wanted to add that it appears to be a DMA related problem. If I disable DMA on my hard disk (hdparm -d 0 /dev/hda) the problem goes away. Does the SB Live use DMA, and how can I figure out which channel it uses. Its been a while since I knew the ins and outs of a sound blaster card, and that was back when SB 2.0 was what I had and I coded in DOS. I know very little about PCI and how data gets between the card and computer memory, etc. If someone could enlighten me in this area I would appreciate it, maybe just a pointer to some docs on the SB Live hardware. Cheers.. Josh Green ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Full duplex test with SB Live
I finally got around to doing a full duplex test with my SB Live card. At first I was experiencing the same problems I was having a while back (although to a lesser degree) with clicks increasing/decreasing in intensity over time. I was searching the ALSA archives (with google as geocrawler is useless) when alsa-lib/test/latency.c was brought to my attention. This program works fine with full duplex, no clicks (except on overruns of course). I did notice that it likes to take 100% CPU which isn't so nice when running SCHED_RR. It looks like snd_pcm_link is what does the magic. Putting this in my test program makes things work all nice and sweet :) Is this function call required in a program to synchronize PCMs or can this be done externally (asound.conf?). Looking forward to vocoding and doing other cool real time PCM effects :) -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Full duplex test with SB Live
On Mon, 2001-10-15 at 02:46, Jaroslav Kysela wrote:
On 15 Oct 2001, Josh Green wrote:
I finally got around to doing a full duplex test with my SB Live card.
At first I was experiencing the same problems I was having a while back
(although to a lesser degree) with clicks increasing/decreasing in
intensity over time. I was searching the ALSA archives (with google as
There shouldn't be any clicks (only on xruns). Could you show me your
code?
Sure, I'll attach it to this email. I've been testing it for a while now
and I'm realizing that the problem hasn't completely gone away. Since
the start/prepare operations happen in sync, each time an xrun occurs
the two devices are resynced. If I start it as root (I'm setting
SCHED_FIFO currently) the test will rarely get xruns. For the most part
the test runs smooth, but every once in a while little pops and clicks
will be heard in series. They increase in # and then decrease and
dissapear again (in a periodic fashion, sometimes sounds like a
scratched vinyl record). This is the same problem, just a lot harder to
reproduce, since it seems the two buffers are much more syncronized.
geocrawler is useless) when alsa-lib/test/latency.c was brought to my
attention. This program works fine with full duplex, no clicks (except
on overruns of course). I did notice that it likes to take 100% CPU
which isn't so nice when running SCHED_RR. It looks like snd_pcm_link
is what does the magic. Putting this in my test program makes things
work all nice and sweet :) Is this function call required in a program
to synchronize PCMs or can this be done externally (asound.conf?).
This call is a part of API and it changes the behaviour of some functions
(it means that all operations are synced and you need to start/stop only
one stream from the linked group).
Yeah. But does a program need to have special support for full duplex
mode or can a program that has a configurable input and output device be
used without problems? (ecasound in particular)
Jaroslav
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
#include stdio.h
#include alsa/asoundlib.h
#include string.h
#include sched.h
#define OK 0
#define FAIL 1
char *audiobuf = NULL;
int audiobuf_bytes = 0;
snd_pcm_t *cards[2] = { NULL };
int fdcount = 0;
struct pollfd *ufds = NULL;
int
setup_device (int index, char *device, int read)
{
int err;
snd_pcm_t *handle;
snd_pcm_hw_params_t *params; /* Hardware parameters */
snd_pcm_sw_params_t *swparams; /* Software parameters */
int period_size; /* Number of frames in period */
int period_bytes; /* size of period */
int buffer_size; /* size of entire audio buffer */
unsigned int rate;
snd_pcm_uframes_t start_threshold, stop_threshold;
int count;
/* Open output sound card */
if (err = snd_pcm_open (handle, device,
read ? SND_PCM_STREAM_PLAYBACK : SND_PCM_STREAM_CAPTURE,
SND_PCM_NONBLOCK) 0)
{
fprintf (stderr, snd_pcm_open failed: %s\n, snd_strerror (err));
return (FAIL);
}
cards[index] = handle;
snd_pcm_hw_params_alloca (params);
snd_pcm_sw_params_alloca (swparams);
snd_pcm_hw_params_any (handle, params);
snd_pcm_hw_params_set_access(handle, params,
SND_PCM_ACCESS_RW_INTERLEAVED);
snd_pcm_hw_params_set_format (handle, params,
SND_PCM_FORMAT_S16_LE);
snd_pcm_hw_params_set_channels (handle, params, 1);
rate = snd_pcm_hw_params_set_rate_near (handle, params, 44100, 0);
period_size = 384;
if (snd_pcm_hw_params_set_period_size (handle, params, period_size, 0) 0)
{
fprintf (stderr, Failed to set period size!\n);
return (FAIL);
}
buffer_size = period_size * 2;
if (snd_pcm_hw_params_set_buffer_size (handle, params, buffer_size) 0)
{
fprintf (stderr, Failed to set buffer size!\n);
return (FAIL);
}
err = snd_pcm_hw_params (handle, params);
/* set software parameters */
snd_pcm_sw_params_current (handle, swparams);
snd_pcm_sw_params_set_sleep_min (handle, swparams, 0);
snd_pcm_sw_params_set_avail_min (handle, swparams, period_size);
start_threshold = (double) rate * (1 / 100);
snd_pcm_sw_params_set_start_threshold(handle, swparams, start_threshold);
stop_threshold = buffer_size;
snd_pcm_sw_params_set_stop_threshold(handle, swparams, stop_threshold);
snd_pcm_sw_params (handle, swparams);
/* Prepare our buffer */
period_bytes = period_size * 2; /* 2 bytes for 16 bit */
if (audiobuf_bytes == 0)
{
audiobuf = malloc (period_bytes);
audiobuf_bytes = period_bytes;
}
else if (audiobuf_bytes != period_bytes)
{
fprintf (stderr, audio buffers not same size (%d != %d)!\n,
audiobuf_bytes, period_bytes);
return (FAIL);
}
count = snd_pcm_poll_descriptors_count (handle);
if (count = 0)
{
fprintf (stderr, invalid poll descriptors count
Re: [Alsa-devel] Full duplex test with SB Live
On Mon, 2001-10-15 at 03:22, Josh Green wrote: Sure, I'll attach it to this email. I've been testing it for a while now and I'm realizing that the problem hasn't completely gone away. Since the start/prepare operations happen in sync, each time an xrun occurs the two devices are resynced. If I start it as root (I'm setting SCHED_FIFO currently) the test will rarely get xruns. For the most part the test runs smooth, but every once in a while little pops and clicks will be heard in series. They increase in # and then decrease and dissapear again (in a periodic fashion, sometimes sounds like a scratched vinyl record). This is the same problem, just a lot harder to reproduce, since it seems the two buffers are much more syncronized. Just wanted to add that my XRUN detection is rather messed up right now, and I've already locked up my machine once (stuck in loop with SCHED_FIFO @:(), so you probably want to run it as non root. Not sure whats wrong with the way I'm detecting XRUNS, but if I just do a snd_pcm_prepare, the output stream starts returning SND_PCM_STATE_PREPARE until I restart it. I'll have to look into it more, but if you have any ideas, please let me know. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Full duplex test with SB Live
On Mon, 2001-10-15 at 05:45, Jaroslav Kysela wrote: On 15 Oct 2001, Josh Green wrote: Just wanted to add that my XRUN detection is rather messed up right now, and I've already locked up my machine once (stuck in loop with SCHED_FIFO @:(), so you probably want to run it as non root. Not sure whats wrong with the way I'm detecting XRUNS, but if I just do a snd_pcm_prepare, the output stream starts returning SND_PCM_STATE_PREPARE until I restart it. I'll have to look into it more, but if you have any ideas, please let me know. There are many thinkos in your code. I found these bugs: 1) initial write: the ring buffer should contain data for two periods before the streams are started 2) xrun recovery: if you call snd_pcm_prepare, you have to call snd_pcm_start, too; otherwise the state will be SND_PCM_STATE_PREPARED 3) count of written / read frames is invalid for i/o operations (you're using count in bytes) 4) poll is not synchronized as you think; it's the main problem causing scratchy sound; you must always preserve the order of read/write i/o calls; please, look to 'r' variable and for unsync messages in my code I've attached my test code (heavy modified) which shows or fixes all above bugs. Have a clear sound, Jaroslav Cool, thanks for the tips and fixes :) Must go to sleep now, sun almost rising. I finally figured out how to record the Mic input on one channel and the Music (wavetable) on another with my SB Live and ALSA (have to use amixer). This setup is nice for the LADSPA vocoder plugin (http://www.c0nfusion.org/~josh/). Perhaps I should throw together a sound font of good carrier sounds. Thanks again! -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] alsalib API programmers guide (was: Alsa Wiki? See myprototype!)
On Mon, 2001-10-15 at 12:55, Kevin Conder wrote: What are your plans for documentation? I propose we could keep the doxygen stuff the way it is and it would be an API Reference Manual. Then we could create a new document that would help application programmers, this would be an ALSA Programmer's Guide. I've seen several requests from application developers on this list for simple code examples to look at. I thought the ALSA Programmer's Guide would step someone through the process of creating simple applications: WAV player, mixer, MIDI player, etc. If someone needed more detail, they could dive into the API Reference manual. I'd be willing to take plain text submissions for a programmer's guide, edit them (spelling, grammar, etc.), format them for DocBook, and publish it all into PDF and HTML. I've converted the ALSA mini-HOWTO to DocBook, so I have experience doing this. -- kevin at kevindumpscore dot com When I read the API documentation I find whats missing the most is definitions of what different terms mean and how they relate to one another. The PCM (digital audio) interface link off of the doxygen alsalib API Main Page looks like a start of what I'm talking about. Ohh, I just realized that this is what Jaraslav just created. Looks good. On another note, some pages seem to be awefully long (the group_pcm.html page for instance). Is it possible to split things like this with doxygen? -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hang up during latency test
On Fri, 2001-10-05 at 03:29, Takashi Iwai wrote: At 04 Oct 2001 19:21:35 -0700, Josh Green wrote: Aggh.. I just ran a whole bunch of ALSA latencytests with various drivers/kernels, all with fairly bad results :( I even went back to my older kernel (2.4.5 with Andrew Morton's patch) with my AWE 32 card, which I had good results with before, and got like 5 to 8ms spikes. I'm not sure what the heck is going on with my machine now, but its certainly not good. I feel that your old results were too good. But the new results seem also too bad compared with mine. Or any hardware changes? hdparm, APM, etc.. I've been suspicious of that myself (the part about my old results being too good). Of course the sound output never had a glitch, whereas now I hear them sometimes (and the output is fairly fuzzed up, how would I send the audio stream with ALSA to a file? I've seen it on the list before, perhaps I would search the archives if geocrawler searched!). Of course I can't be sure how big the audio buffers were as there were some issues with oss emulation under ALSA with latencytest. Are there any programs that report what piece of code is causing big spikes? I haven't tested the 2.4.10 kernel yet, and if I did it would be bare without any patches (as I don't know of any up to date with 2.4.10). I did realize that the 2.4.9 kernel with LL patch is worse than the 2.4.5 one I was using. This might be because I compiled it with Mandrake's gcc a la 2.96. As far as I've experienced, the VM of 2.4.9 tends to have higher latency under heavy disk loads. On 2.4.10 the VM was changed much and became better. I discussed with Andrea about this problem, and he will check the relevant part. Hopefully any patch will come to 2.4.11. Sounds good. I noticed the memory management got worked heavily between 2.4.9 and 2.4.10. I couldn't really just logically do a manual apply of rejects for the LL patch for 2.4.9. Its nice to hear that its for the better :) By the way I'm posting my results to http://www.c0nfusion.org/~josh/ if you want to have a look. The only hardware that has changed in my machine since my previous tests (http://www.resonance.org/~josh/) is I added an SB Live!. I think I upgraded to Mandrake 8 between then, so most of the software is probably different. Ah, the last test looks really fantastic.. I wish in near future we get it back! Alas, the last test is with OSS (my test #4 was with ALSA though, which has similar #s as far as latency). I wonder about the OSS latencytest though. It seems like the latency is fairly equivelant. The only difference being the huge # of overruns with ALSA compared to OSS. I wonder if the OSS overrun detection is correct. I haven't looked at the latencytest code recently, but I seem to remember it manually determining if an overrun was caused or not (by comparing the latency with the fragment period). I also noticed that the buffer size with OSS was 1024 rather than 768 bytes. I think this is just one extra fragment though, so that shouldn't affect it right? ciao, Takashi Not sure if you saw my question about whether there is some way to determine where in the kernel a hold up occurs. How does Andrew Morton check those things? Seems like a tool to determine what driver, program or kernel routine is causing latency spikes would be a useful tool. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Opening device default with alsa09 and emu10k1card.
On Fri, 2001-10-05 at 14:27, James Courtier-Dutton wrote: Hello When I open device default with alsa09 and a emu10k1 card. The volume control for this output in alsamixer is Wave Sur I think that this should be PCM instead. Which is the correct way to control volume of a PCM stream with alsa09. Cheers James -- Nothing in this world is exactly what it appears to be. This one got me too. You have your speakers plugged into the wrong output. The jack closest to the Joystick port on the SB Live is for the Rear speakers (i.e. Surround) whereas the next one over (second jack from Joystick port) is the front output, which will probably act more like what you want. Sometime an ALSA SB Live FAQ should be written, its taken me a while to get used to all the quirks. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Kernel oops in snd-card-emu10k1 with latest CVS
I've been getting a kernel oops with the latest CVS (as of today). I've attached the output from ksymoops. I CAN get it to re-occur. Running Smurf, loading up a sound font, and playing a bunch of notes eventually causes Smurf to segfault, with the kernel oops in my system log. -- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net) ksymoops 2.4.1 on i586 2.4.9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.9/ (default) -m /boot/System.map-2.4.9 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address fbba049e c89752e7 *pde = Oops: CPU:0 EIP:0010:[c89752e7] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210082 eax: fbba047a ebx: c6e5c8c0 ecx: c7728000 edx: d804 esi: 0001 edi: c6e36800 ebp: esp: c19c3d58 ds: 0018 es: 0018 ss: 0018 Process smurf (pid: 1063, stackpage=c19c3000) Stack: c6e5c8c0 c896d30d c6e5c8c0 00200246 003e c343ee60 000b 8001 c6e5c6e0 c6e36800 c896d424 00200282 00200282 c7aae000 0026 c6d79ce0 c6d79ce0 c896835b c6d79ce0 0026 007f c7aae000 c19c3f4c c6d79ce0 Call Trace: [c896d30d] [c896d424] [c896835b] [c896819d] [c89700ab] [c8970743] [c8970648] [c89521d3] [c896e502] [c8972a40] [c8952abc] [c8952c20] [__kfree_skb+226/240] [c8952dba] [c8952fe0] [pipe_poll+41/112] [c89532ca] [c8952c20] [c01e1632] [c8952dba] [c8952fe0] [c01398f9] [c89532ca] [c01de75a] [c01300d5] [c0106dc3] Code: 8b 50 24 85 d2 74 0b 8b 42 18 85 c0 74 04 48 89 42 18 5b c3 EIP; c89752e7 [snd-synth-emu10k1]terminate_voice+27/40 = Trace; c896d30d [snd-synth-emux]snd_emux_note_on+ad/180 Trace; c896d424 [snd-synth-emux]snd_emux_note_off+44/70 Trace; c896835b [snd-seq-midi-emul]note_off+5b/70 Trace; c896819d [snd-seq-midi-emul]__kstrtab_snd_midi_channel_free_set+7d/1e0 Trace; c89700ab [snd-synth-emux]sf_zone_new+3b/50 Trace; c8970743 [snd-synth-emux]set_sample+13/50 Trace; c8970648 [snd-synth-emux]load_info+2c8/300 Trace; c89521d3 [snd-seq]snd_seq_client_use_ptr+23/f0 Trace; c896e502 [snd-synth-emux]snd_emux_event_input+12/20 Trace; c8972a40 [snd-synth-emux]emux_ops+0/1c Trace; c8952abc [snd-seq]snd_seq_deliver_single_event+dc/140 Trace; c8952c20 [snd-seq]deliver_to_subscribers+100/150 Trace; c8952c20 [snd-seq]deliver_to_subscribers+100/150 Trace; c01e1632 __kfree_skb+e2/f0 Trace; c8952dba [snd-seq]snd_seq_deliver_event+3a/c0 Trace; c8952fe0 [snd-seq]snd_seq_client_enqueue_event+70/120 Trace; c01398f9 pipe_poll+29/70 Trace; c89532ca [snd-seq]snd_seq_write+1ba/200 Trace; c01de75a sock_read+8a/a0 Trace; c01300d5 sys_write+95/d0 Trace; c0106dc3 system_call+33/40 Code; c89752e7 [snd-synth-emu10k1]terminate_voice+27/40 _EIP: Code; c89752e7 [snd-synth-emu10k1]terminate_voice+27/40 = 0: 8b 50 24 mov0x24(%eax),%edx = Code; c89752ea [snd-synth-emu10k1]terminate_voice+2a/40 3: 85 d2 test %edx,%edx Code; c89752ec [snd-synth-emu10k1]terminate_voice+2c/40 5: 74 0b je 12 _EIP+0x12 c89752f9 [snd-synth-emu10k1]terminate_voice+39/40 Code; c89752ee [snd-synth-emu10k1]terminate_voice+2e/40 7: 8b 42 18 mov0x18(%edx),%eax Code; c89752f1 [snd-synth-emu10k1]terminate_voice+31/40 a: 85 c0 test %eax,%eax Code; c89752f3 [snd-synth-emu10k1]terminate_voice+33/40 c: 74 04 je 12 _EIP+0x12 c89752f9 [snd-synth-emu10k1]terminate_voice+39/40 Code; c89752f5 [snd-synth-emu10k1]terminate_voice+35/40 e: 48dec%eax Code; c89752f6 [snd-synth-emu10k1]terminate_voice+36/40 f: 89 42 18 mov%eax,0x18(%edx) Code; c89752f9 [snd-synth-emu10k1]terminate_voice+39/40 12: 5bpop%ebx Code; c89752fa [snd-synth-emu10k1]terminate_voice+3a/40 13: c3ret 1 warning issued. Results may not be reliable.
