Re: [Alsa-devel] usb-audio
At Wed, 29 Oct 2003 23:26:07 +0100, Niklas Werner wrote: Am Mittwoch, 29. Oktober 2003 19:24 wurde geschrieben: At Tue, 28 Oct 2003 20:18:35 +0100, hmm, it seems that a wrong label is used. the label should be conv_xx12_xx21 (= conv_labels[35]). something is really broken. could you check stepwise the loop there? still checking (any tips on speeding this up (I'm trying step 8 atm?), seems to happen after the first set of frames (=16384) is processed. in the first process, did it go to conv_xx12_xx21 properly? the label stays wrong throughout the whole loop, the convidx stays 35 thanks for check. can you hear a clear sound with aplay -M ? Yes :-) at least, something still good :) Takashi --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [patch] Envy24control access to 6Fire controls
Hi Daniel, This patch against the stable version of envy24control gives access to most of the Terratec DMX 6Fire mixer controls. It also changes the lables on the inputs in the monitor mixer to be more useful. It should have no effect on your envy24control if you are using a card other than the 6Fire. Works fine for me, nice to finally have the input switches available in envy24control. Though envy24control really is flexible, I always wished to have an less complex mixer for the DMX6Fire, but never took the time to write one or patch e24c for that purpuse. So if you ever get in that mood again, it would be nice if you could also change the other labels in the patchbay/router tab and the analog volume tab. (ADC0-In CD L , ADC1-In CD R, ..., IGPA 0 - Gain CD-L, IPGA 1 - Gain CD-R ...). And I really wish I had a mixer that would handle the stereo channels as what they are. Its annoying to have 6 sliders for adjusting the volume of your line-in, for example, but since you're no programmer, you probably won't fix that :) Note that I'm not a programmer, so there might be huge errors in this... Haven't really looked at the code, but it seems to work flawlessly. gruß, Steffen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] usb-audio
At Thu, 30 Oct 2003 13:42:14 +0100, Niklas Werner wrote: Am Donnerstag, 30. Oktober 2003 13:17 schrieb Takashi Iwai: At Wed, 29 Oct 2003 23:26:07 +0100, Niklas Werner wrote: Am Mittwoch, 29. Oktober 2003 19:24 wurde geschrieben: At Tue, 28 Oct 2003 20:18:35 +0100, hmm, it seems that a wrong label is used. the label should be conv_xx12_xx21 (= conv_labels[35]). something is really broken. could you check stepwise the loop there? still checking (any tips on speeding this up (I'm trying step 8 atm?), seems to happen after the first set of frames (=16384) is processed. in the first process, did it go to conv_xx12_xx21 properly? nope: 0x0fd422f4 184 goto *conv; (gdb) si 299 conv_1234_xx21: as_u16(dst) = bswap_16(as_u32c(src) 16); goto hmm, really weird. meanwhile, i rewrote snd_pcm_linear_convert() without goto trick. could you try the attached patch? Takashi pcm_linear_flatten.dif Description: Binary data
Re: [Alsa-devel] [PATCH] serial-u16550 driver. Fixes buffer blocking bug
Takashi, Thanks for your response. I've addressed your issues below. Let's discuss this and if necessary I'll modify my fix. 1. Move all checks of buffer overflow and such to the actual buffer write and read routines. This makes the buffer routines more robust and encaspulates buffer opperations better. the check in the caller may be still needed for the multi-bytes write (e.g. for switching the port). otherwise, the port-switch command can be mixed and messed up when the device is accessed concurrently. I thought about this, but decided it's not a large issue since it is mitigated by the natural operation of the driver. For normal opperation: As this is called with interupts off, the process can't be interupted. The function doesn't return until after we've drained the snd_rawmidi_transmit(), and if we do decide to insert a f5... msg, we do the whole msg before we can return. So, no issue durring normal opperation. So concurrent access doesn't apear to be a large issue. If buffer gets full: Yes, it is possible for an f5... msg to get interupted. BUT, I don't see this as a large problem. On return to normal opperation (ie. the buffer begins draining again), the proper port-switch command will be written in correctly when the port gets switched, or in the next three seconds, whichever comes first. Perhaps some data gets sent to the wrong port, but it autocorrects very quickly. While this condition technically is possible, I haven't seen it happen in practice, and even if it does it would correct itself quickly. For another mittigating factor, please see my answer to #2 below. If you're still concerned about this, I have an alternate fix that would keep a check, but not interfeare with opperation. 2. Always try to send data to the buffers. Don't interupt normal opperation of the algoritim because buffers are full. This was what was actually causing the data to be left in rawmidi and thus causing it to lock up. This is helped by moving the buffer size checks into the routines. this is the questionary behavior. the fact that the local buffer is full means that the transfer doesn't work. so, it is quite correct behavior that rawmidi blocks the further write (in blocking mode), i think. and, it should return -EAGAIN in non-blocking mode. or, at least, we can make the behavior selectable: abandon or block. Well, the driver already was trying to opperate in the mode where it was abandoning bytes, it was just doing a bad job of it. All I did was fix it so it actually abandoned all bytes that didn't fit in the buffers. Before it was grabbing a byte from snd_rawmidi_transmit() and if no room was in the buffer it would break out of the while(1) loop. So, basically it would abandon the first byte on its execution, but leave some data there for later. This caused a problem with rawmidi's buffers seeming to back up and eventually hanging up the driver (recoverable only via reopening the device). The program (call it pdr) we have using this device operates in blocking mode. So, if things worked properly, pdr would attempt to write the midi msg, and the snd_seq_event_output() just wouldn't return until it was able to send the data. That would be fine. BUT, if we physically disconnect the serial cable from the device, after awhile, the buffer in serial-u16550.c fills up, then one byte is retrieved from snd_rawmidi_transmit() (and then discarded by the driver) for every three bytes put into the rawmidi buffers, these buffers fill up and eventually cause the lockup of the driver, all while never reporting a problem back to pdr (snd_seq_event_output() seems not to block even though we're in blocking mode). As far as pdr seems to know, it's able to always send data, but eventually the data stops getting to the physical device (as a side note, midi data that avoids the rawmidi buffers via snd_seq_event_output_direct() will get written to the device properly even in this case). So, now the driver reliably drops all data given to it if the buffers are full, not just some of the data and rawmidi buffers never get backed up, the driver doesn't lockup and everything works properly when the device gets pluged back in. Personally, I feel it IS proper behavior. Simple fact is, if the condition happens where this buffer gets filled in, the midi events have been released by alsa to go out to the device immedately, but have now been delayed by up to 30-40 minutes. They're past their prime and are really no longer relevant. If we discard data, well, tough. At this point it becomes about error recovery, not valid data. This code recovers proper opperation, where the old code didn't. This method works best for our application. However, if we want different behavior, let me know how to do this. I was able to fix the problem here, without digging further into the rawmidi code or even further up the chain. Frankly I'm not educated enough on that
[Alsa-devel] aureal driver compile problem and patch
(I already attempted to send this message to the list once before I subscribed, but it never showed up in the archives. My apologies if this ends up being a duplicate post. -ELH) Hello, I'm running RedHat 7.3 with all updates applied (including RedHat's kernel version 2.4.20-20.7), with a generic OEM Aureal Vortex soundcard (au8820 chip). On this system, I compiled ALSA driver 0.9.8 with the following options: [EMAIL PROTECTED] alsa-driver-0.9.8]$ ./configure --with-isapnp=no --with-sequencer=yes --with-oss=yes --with-cards=au8820 Performing a 'make; make install' ends with a message saying that there are unresolved symbols in module snd-au8820.o. Digging a bit deeper, we can find which symbols are unresolved: [EMAIL PROTECTED] alsa-driver-0.9.8]# depmod -ae depmod: *** Unresolved symbols in /lib/modules/2.4.20-20.7/kernel/sound/pci/au88x0/snd-au8820.o depmod: snd_mpu401_uart_new_Ra9ec76fd depmod: snd_mpu401_uart_interrupt_Rff6d4aa3 depmod: snd_ac97_mixer_Rdd7e1738 By comparing the ALSA driver 0.9.8 source tree to the CVS repository at the OpenVortex web site where the vortex driver was developed, I found that there were some missing lines in several Makefiles in the ALSA tree. In the OpenVortex CVS repository, these lines appear in Makefiles under alsa-kernel/ but my understanding is that a driver shouldn't touch these files until it is included in alsa-kernel/, so I added the lines to the corresponding Makefiles outside of alsa-kernel/. I'm not 100% sure if all the dependencies I've added are necessary--I just blindly copied lines from the OpenVortex CVS. Someone with a better understanding of the driver can double-check me. After making these modifications (see patch below), the vortex driver compiled with no unresolved symbols on my system, and is working great. Thanks to ALSA and the OpenVortex guys for getting my soundcard working without having to use the old binary-only Aureal driver. -Eric Hathaway --- BEGIN PATCH --- diff -ur alsa-driver-0.9.8/acore/Makefile alsa-driver-0.9.8-patched/acore/Makefile --- alsa-driver-0.9.8/acore/MakefileTue Sep 16 06:14:03 2003 +++ alsa-driver-0.9.8-patched/acore/MakefileTue Oct 21 22:21:12 2003 @@ -10,6 +10,9 @@ obj-$(CONFIG_SND_SERIALMIDI) += snd-rawmidi.o snd.o obj-$(CONFIG_SND_MSND_PINNACLE) += snd-pcm.o snd-timer.o snd-page-alloc.o snd.o snd-rawmidi.o obj-$(CONFIG_SND_USB_US428) += snd-pcm.o snd-timer.o snd-page-alloc.o snd.o snd-rawmidi.o snd-hwdep.o +obj-$(CONFIG_SND_AU8810) += snd-pcm.o snd-timer.o snd-page-alloc.o snd.o snd-rawmidi.o +obj-$(CONFIG_SND_AU8820) += snd-pcm.o snd-timer.o snd-page-alloc.o snd.o snd-rawmidi.o +obj-$(CONFIG_SND_AU8830) += snd-pcm.o snd-timer.o snd-page-alloc.o snd.o snd-rawmidi.o export-objs := sound.o pcm.o pcm_lib.o rawmidi.o timer.o hwdep.o memalloc.o diff -ur alsa-driver-0.9.8/acore/seq/Makefile alsa-driver-0.9.8-patched/acore/seq/Makefile --- alsa-driver-0.9.8/acore/seq/MakefileMon Jun 2 09:03:38 2003 +++ alsa-driver-0.9.8-patched/acore/seq/MakefileTue Oct 21 22:21:20 2003@@ -7,6 +7,9 @@ obj-$(CONFIG_SND_SERIALMIDI) += snd-seq-midi.o snd-seq.o snd-seq-device.o snd-seq-midi-event.o obj-$(CONFIG_SND_MSND_PINNACLE) += snd-seq-midi.o snd-seq.o snd-seq-device.o snd-seq-midi-event.o +obj-$(CONFIG_SND_AU8810) += snd-seq-midi.o snd-seq.o snd-seq-device.o snd-seq-midi-event.o snd-seq-instr.o +obj-$(CONFIG_SND_AU8820) += snd-seq-midi.o snd-seq.o snd-seq-device.o snd-seq-midi-event.o snd-seq-instr.o +obj-$(CONFIG_SND_AU8830) += snd-seq-midi.o snd-seq.o snd-seq-device.o snd-seq-midi-event.o snd-seq-instr.o export-objs := seq_device.o seq.o seq_instr.o seq_midi_emul.o \ seq_midi_event.o seq_virmidi.o diff -ur alsa-driver-0.9.8/drivers/mpu401/Makefile alsa-driver-0.9.8-patched/drivers/mpu401/Makefile --- alsa-driver-0.9.8/drivers/mpu401/Makefile Mon Jun 2 09:03:39 2003 +++ alsa-driver-0.9.8-patched/drivers/mpu401/Makefile Tue Oct 21 22:21:36 2003@@ -3,6 +3,10 @@ include $(TOPDIR)/toplevel.config include $(TOPDIR)/Makefile.conf +obj-$(CONFIG_SND_AU8810) += snd-mpu401-uart.o +obj-$(CONFIG_SND_AU8820) += snd-mpu401-uart.o +obj-$(CONFIG_SND_AU8830) += snd-mpu401-uart.o + export-objs := mpu401_uart.o TOPDIR = $(MAINSRCDIR) diff -ur alsa-driver-0.9.8/pci/ac97/Makefile alsa-driver-0.9.8-patched/pci/ac97/Makefile --- alsa-driver-0.9.8/pci/ac97/Makefile Sun Feb 9 13:35:57 2003 +++ alsa-driver-0.9.8-patched/pci/ac97/Makefile Tue Oct 21 22:21:49 2003 @@ -3,6 +3,10 @@ include $(TOPDIR)/toplevel.config include $(TOPDIR)/Makefile.conf +obj-$(CONFIG_SND_AU8810) += snd-ac97-codec.o +obj-$(CONFIG_SND_AU8820) += snd-ac97-codec.o +obj-$(CONFIG_SND_AU8830) += snd-ac97-codec.o + export-objs := ac97_codec.o ak4531_codec.o TOPDIR = $(MAINSRCDIR) --- END PATCH --- --- This SF.net email is sponsored by:
