Re: [Alsa-devel] hdsp update
At Mon, 24 Nov 2003 19:37:37 +0100, Thomas Charbonnel wrote: [1 text/plain; us-ascii (7bit)] Takashi Iwai wrote : I updated hdspmixer and hdspconf to fix all these problems : http://www.undata.org/~thomas/ applied to cvs. thanks! I just checked cvs to send you a clean patch instead, but the latest changes were not in there yet. Sorry for the extra workload this gives you. no problem at all. (blame to sourceforge :) ciao, Takashi Thanks ! While we're at we should shut up the warnings in hdsploader too. Trivial diff attached. applied. thanks! 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] usbaudio fixes
At Tue, 25 Nov 2003 12:51:11 +0100 (CET), Jaroslav wrote: On Mon, 24 Nov 2003, Takashi Iwai wrote: At Mon, 24 Nov 2003 13:51:50 +0100, I wrote: At Mon, 24 Nov 2003 13:36:42 +0100, I wrote: meanwhile, i'm trying to implement: (4) allow prepare callback to sleep with a special flag. this will be useful for other drivers, too, such as vx and korg1212 drivers which require the handshaking. but what i'm doing is still a hack, and will be a fundamental rewrite later. the attached is a quick-hacked version. it's untested for linked streams. we need a test case here. ok, here is the final version. this one seems working fine. Jaroslav, could you check whether it's ok? the changes in pcm_native.c shouldn't affect other cards. It's ok, but it still looks like an ugly hack, but I don't see any other way to solve this problem so you can apply this code to CVS. yeah, agreed, it's a quick'n'dirty hack :) the better way would be to move all prepare callback in every driver as non-atomic, and call it inside a mutex. linking/unlinking streams will need to issue both a mutex and a spinlock for prepare and trigger callbacks. but, for this, we have to audit all drivers. let's beautify later. ok, i'll commit the changes now. thanks, 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] add support for mandrake in alsaconf
At Mon, 24 Nov 2003 20:33:40 +, Thierry Vignaud wrote: Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes: Options: a) define 'distribution=redhat' for the mandrake detection code _if_ the oss options erasure for redhat works fine under mandrake (mandrake users should test this). b) add another handler for mandrake's modules.conf oss options (should be written taking into account whatever mandrake uses to configure sound so that the proper strings are removed from modules.conf). so why not doing such as threat all distros that provide /etc/redhat-release the same way. i don't think there's any distro out that provide /etc/redhat-release for compatibility that would like to have users loose their module configuration: With the patch I supplied no distros that user /etc/redhat-release will lose their configuration (I hope, at least not due to the bug I introduced a long time ago which is fixed by the patch). Distros that are not RedHat or Fedora will execute the SuSE code path. Your patch is fine, I would say. But it has an assumption I don't quite like. I wrote remove_sndconfig_block (basing it on remove_y2_block) by looking at all the strings that the sndconfig utility was adding to modules.conf (sndconfig was the way RedHat was doing sound configuration quite a while ago, I think this has changed). as for mandrake, we do not rely on sndconfig (though we still provide it for isa pnp sound card owners) drakx (the installer) and draksound (the standalone soundconfig tool) only write sound-slot-X aliases and above XXX snd-pcm-oss lines for oss compatibility (if $module =~ /^snd-/) in /etc/modules.conf then remove_y2_block() would be enough. i'll take Thierry's first patch. it will be in pre3 release. 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
[Alsa-devel] [PATCH]Firmware for us122 us224 Part1
Hi Takashi, to complete support for us122 and make it easy for developers to add us224 support, please commit this stuff to alsa-tools/usx2yloader. Thanks, Karsten Index: alsa-tools/usx2yloader/firmware/Makefile.am === RCS file: /cvsroot/alsa/alsa-tools/usx2yloader/firmware/Makefile.am,v retrieving revision 1.2 diff -u -r1.2 Makefile.am --- alsa-tools/usx2yloader/firmware/Makefile.am 23 Sep 2003 14:16:23 - 1.2 +++ alsa-tools/usx2yloader/firmware/Makefile.am 25 Nov 2003 12:39:22 - @@ -1,4 +1,9 @@ -cfg_files = us428.conf us428.prepad us428.rbt tascam_loader.ihx us428fw.ihx +cfg_files = us122.conf us224.conf us428.conf \ + usx2y.prepad us428.prepad \ + us122.rbt us224.rbt us428.rbt \ + tascam_loader.ihx \ + us122fw.ihx us224fw.ihx us428fw.ihx + EXTRA_DIST = $(cfg_files) firmwaredir = $(datadir)/alsa/firmware usx2yloader_firmware_122.tar.bz2 Description: application/tbz
[Alsa-devel] [PATCH]Firmware for us122 us224 Part2
Hi Takashi, to complete support for us122 and make it easy for developers to add us224 support, please commit this stuff to alsa-tools/usx2yloader. Thanks, Karsten usx2yloader_firmware_224.tar.bz2 Description: application/tbz
Re: [Alsa-devel] Bug in rme9652 or snd_pcm_hw_params_set_rate_near()? (slave clock stuff)
If my hammerfall (rme9652) sound card is locked slave to 48 kHz, and I put 44.1 kHz into snd_pcm_hw_params_set_rate_near for playback it accepts it, should it really be that way? I expected that it would set the rate to 48kHz, since the card does not change the sample rate to 44.1 kHz (looking in /proc), when I start playing the rate is indeed 48kHz. the 9652 driver needs revamping to match the behaviour of the hdsp. thomas did great work on this, and the model for how it works is much better than the 9652 driver. put simply, the 9652 driver really doesn't this properly. the hdsp driver works, IIRC, pretty much as you suggest. if its in master mode, you can set the rate, if its slaved, you cannot. --p --- 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
[Alsa-devel] [PATCH] - Minor specfile update for alsa-utils
Include all man pages (alsaconf(8) was not included before)
--
Ronny V. Vindenes [EMAIL PROTECTED]
--- alsa-utils-1.0.0pre1/utils/alsa-utils.spec.in 2003-05-15 08:51:29.0 +0200
+++ fix/alsa-utils-1.0.0pre1/utils/alsa-utils.spec.in 2003-11-25 15:40:43.160825243 +0100
@@ -18,6 +18,9 @@
Advanced Linux Sound Architecture (ALSA) - Utils
%changelog
+* Tue Nov 25 2003 Ronny V. Vindenes [EMAIL PROTECTED]
+- include all manpages
+
* Thu Mar 6 2003 Ronny V. Vindenes [EMAIL PROTECTED]
- removed wrongly included doc file
@@ -60,4 +63,4 @@
%{_prefix}/sbin/*
%{_prefix}/bin/*
-%{_mandir}/man1/*
+%{_mandir}/man?/*
[Alsa-devel] Sony VAIO I810 system freeze
Hi, I just tried to help someone with a Sony VAIO + i810 audio device to install the latest ALSA driver. As soon as any access to the device occurs the system freezes. I tried 0.9.8 and 1.0.0pre2; same result. The OSS driver works, but skips all the time. The installed OS was SUSE 8.0 (by the way, what an annoyance to install kernel modules, version mismatch, no kernel headers .) Its an VAIO Pentium 4 (very small Notebook). I didn't had the chance to get a lspci output, sorry. I haven't take much care about intel810 issues since i don't use such hardware, but that driver seems to definitely need some stability improvements. I hope someone of the intel8x0 guys can take a look and wipe out away the nitroglycerin. Best Regards --- 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] Sony VAIO I810 system freeze
At Tue, 25 Nov 2003 13:10:48 -0400, Manuel Jander wrote: Hi, I just tried to help someone with a Sony VAIO + i810 audio device to install the latest ALSA driver. As soon as any access to the device occurs the system freezes. I tried 0.9.8 and 1.0.0pre2; same result. The OSS driver works, but skips all the time. ACPI problem? The installed OS was SUSE 8.0 (by the way, what an annoyance to install kernel modules, version mismatch, no kernel headers .) the newer kernel may work better in this regard... Its an VAIO Pentium 4 (very small Notebook). I didn't had the chance to get a lspci output, sorry. I haven't take much care about intel810 issues since i don't use such hardware, but that driver seems to definitely need some stability improvements. unfortunately, the driver itself can't do so much. also, onboard sound on notebook is in general horrible to support. I hope someone of the intel8x0 guys can take a look and wipe out away the nitroglycerin. 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
[Alsa-devel] Re: 2.6.-test10: bad __might_sleep in ALSA sound drivers
Hi,
At Mon, 24 Nov 2003 18:00:17 -0800,
Andrew Morton wrote:
Torrey Hoffman [EMAIL PROTECTED] wrote:
I get this every time I boot 2.6.0-test10. I think this problem has
been around for a while.
Debug: sleeping function called from invalid context at
include/asm/semaphore.h:119
in_atomic():1, irqs_disabled():0
Call Trace:
[c01229d0] __might_sleep+0xab/0xc9
[fcff57bd] ap_cs8427_sendbytes+0x38/0xd2 [snd_ice1712]
[fcfa825a] snd_i2c_sendbytes+0x22/0x26 [snd_i2c]
[fcfaf15e] snd_cs8427_reg_read+0x2c/0x8c [snd_cs8427]
[fcfaf414] snd_cs8427_create+0xa4/0x347 [snd_cs8427]
[c02dc4b0] snd_device_new+0x20/0x6a
[fcff151a] snd_ice1712_init_cs8427+0x2f/0x6f [snd_ice1712]
[fcff6153] snd_ice1712_delta_init+0x230/0x2b9 [snd_ice1712]
[fcff5227] snd_ice1712_probe+0x323/0x34c [snd_ice1712]
snd_cs8427_create() does:
snd_i2c_lock(bus);
if ((err = snd_cs8427_reg_read(device, CS8427_REG_ID_AND_VER)) !=
CS8427_VER8427A) {
the first statement takes a spinlock. snd_cs8427_reg_read() then calls
ap_cs8427_sendbytes() which downs a semaphore.
It might be more appropriate to use a semaphore for ice1712_t.gpio_mutex?
the attached patch fixes this, simply replacing spinlock with mutex.
it's already in ALSA 1.0.0pre release.
--
Takashi Iwai [EMAIL PROTECTED]ALSA Developer - www.alsa-project.org
diff -ru linux/include/sound linux/include/sound
--- linux/include/sound/i2c.h 23 Apr 2002 13:20:58 - 1.3
+++ linux/include/sound/i2c.h 13 Nov 2003 11:18:12 - 1.4
@@ -58,7 +58,7 @@
snd_card_t *card; /* card which I2C belongs to */
char name[32]; /* some useful label */
- spinlock_t lock;
+ struct semaphore lock_mutex;
snd_i2c_bus_t *master; /* master bus when SCK/SCL is shared */
struct list_head buses; /* master: slave buses sharing SCK/SCL, slave: link
list */
@@ -84,15 +84,15 @@
static inline void snd_i2c_lock(snd_i2c_bus_t *bus) {
if (bus-master)
- spin_lock(bus-master-lock);
+ down(bus-master-lock_mutex);
else
- spin_lock(bus-lock);
+ down(bus-lock_mutex);
}
static inline void snd_i2c_unlock(snd_i2c_bus_t *bus) {
if (bus-master)
- spin_unlock(bus-master-lock);
+ up(bus-master-lock_mutex);
else
- spin_unlock(bus-lock);
+ up(bus-lock_mutex);
}
int snd_i2c_sendbytes(snd_i2c_device_t *device, unsigned char *bytes, int count);
diff -ru linux/sound linux/sound
--- linux/sound/i2c/i2c.c 2 Jun 2003 10:04:44 - 1.7
+++ linux/sound/i2c/i2c.c 13 Nov 2003 11:18:25 - 1.8
@@ -84,7 +84,7 @@
bus = (snd_i2c_bus_t *)snd_magic_kcalloc(snd_i2c_bus_t, 0, GFP_KERNEL);
if (bus == NULL)
return -ENOMEM;
- spin_lock_init(bus-lock);
+ init_MUTEX(bus-lock_mutex);
INIT_LIST_HEAD(bus-devices);
INIT_LIST_HEAD(bus-buses);
bus-card = card;
Re: [Alsa-devel] [PATCH]Firmware for us122 us224 Part2
At Tue, 25 Nov 2003 13:55:22 +0100, Karsten Wiese wrote: Hi Takashi, to complete support for us122 and make it easy for developers to add us224 support, please commit this stuff to alsa-tools/usx2yloader. we split the firmware binaries to a new package, alsa-firmware, to reduce the frequent download size. your new files will be into it, too. thanks, 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
[Alsa-devel] Oops still present in lastest CVS/nm256
I've posted this problem before, and the oops reported below seems to be the same one. I just CVS updated and rebuilt in all alsa-* directories. Aplay sigseg's and I get an oops. The first time I tried lead to a hard lockup. After rebooting, all I got was the oops. I'm using the nm256 driver on a Sony Z505S viao notebook with 2.4.22 of the kernel (with lowlatency and preemptive patches applied). [The usual kernal driver works fine and I have it configured to build as a module]. I'm using gcc 3.3.2 and configure with the following flags: In alsa-lib --with-debug=no --with-gnu-ld In alsa-driver --with-cards=nm256 --with-sequencer=yes In alsa-oss --disable-alsatest --with-gnu-ld Finally, much earlier versions of alsa (say 6 months old) worked in my setup, at least on earlier versions of the kernel. Here's what ksymoops gives: === ksymoops 2.4.9 on i686 2.4.22. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.22/ (default) -m /usr/src/linux/System.map (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. Warning (compare_maps): ksyms_base symbol IO_APIC_get_PCI_irq_vector_R__ver_IO_APIC_get_PCI_irq_vector not found in System.map. Ignoring ksyms_base entry Unable to handle kernel NULL pointer dereference at virtual address c0113b58 *pde = Oops: CPU:0 EIP:0010:[c0113b58]Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: c7395984 ebx: c6d48000 ecx: edx: 0003 esi: c7395984 edi: c67576e0 ebp: c6d49f20 esp: c6d49f00 ds: 0018 es: 0018 ss: 0018 Process aplay (pid: 12161, stackpage=c6d49000) Stack: c4115aa0 c7395800 c67576e0 c7395988 cc8a91e0 0001 0286 0003 c739594c cc8a2805 c67576e0 0282 c739595c c739595c c5bd3ae0 c7395800 cc8a40bd c7395800 c67576e0 c5bd3b00 c739595c c67576e0 Call Trace:[cc8a91e0] [cc8a2805] [cc8a40bd] [c0136bc4] [c0135827] [c013588b] [c0106d9b] Code: 8b 01 85 45 fc 74 6a c7 45 f0 00 00 00 00 9c 5f fa ff 43 04 EIP; c0113b58 __wake_up+48/ec = eax; c7395984 _end+70fd3d4/c582ab0 ebx; c6d48000 _end+6aafa50/c582ab0 esi; c7395984 _end+70fd3d4/c582ab0 edi; c67576e0 _end+64bf130/c582ab0 ebp; c6d49f20 _end+6ab1970/c582ab0 esp; c6d49f00 _end+6ab1950/c582ab0 Trace; cc8a91e0 [snd]snd_fops+0/60 Trace; cc8a2805 [snd]snd_card_file_remove+b5/e0 Trace; cc8a40bd [snd]snd_ctl_release+11d/140 Trace; c0136bc4 fput+4c/f8 Trace; c0135827 filp_close+93/a0 Trace; c013588b sys_close+57/7c Trace; c0106d9b system_call+33/38 Code; c0113b58 __wake_up+48/ec _EIP: Code; c0113b58 __wake_up+48/ec = 0: 8b 01 mov(%ecx),%eax = Code; c0113b5a __wake_up+4a/ec 2: 85 45 fc test %eax,0xfffc(%ebp) Code; c0113b5d __wake_up+4d/ec 5: 74 6a je 71 _EIP+0x71 Code; c0113b5f __wake_up+4f/ec 7: c7 45 f0 00 00 00 00 movl $0x0,0xfff0(%ebp) Code; c0113b66 __wake_up+56/ec e: 9cpushf Code; c0113b67 __wake_up+57/ec f: 5fpop%edi Code; c0113b68 __wake_up+58/ec 10: facli Code; c0113b69 __wake_up+59/ec 11: ff 43 04 incl 0x4(%ebx) 2 warnings issued. Results may not be reliable. --- 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] Oops still present in lastest CVS/nm256
At Tue, 25 Nov 2003 12:38:59 -0500, David Ronis wrote: I've posted this problem before, and the oops reported below seems to be the same one. I just CVS updated and rebuilt in all alsa-* directories. Aplay sigseg's and I get an oops. The first time I tried lead to a hard lockup. After rebooting, all I got was the oops. I'm using the nm256 driver on a Sony Z505S viao notebook with 2.4.22 of the kernel (with lowlatency and preemptive patches applied). [The usual kernal driver works fine and I have it configured to build as a module]. what about the kernel without preemptive? i remember this kind of oops, but it happend e.g. when alsa-driver and alsa-kernel versions are not synced, or linux kernel tree doesn't match with the actual one, etc. i don't think it's specific to nm256 driver. 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
[Alsa-devel] config problem
My driver supports several different cards of the same series. Most of the code is common for all cards, so I put the code which is not common into separate .c files. Well, now I need a way to tell make what is the card I want the driver for. -- Giuliano. --- 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] config problem
At Tue, 25 Nov 2003 19:14:38 +0100, Giuliano Pochini wrote: My driver supports several different cards of the same series. Most of the code is common for all cards, so I put the code which is not common into separate .c files. Well, now I need a way to tell make what is the card I want the driver for. sorry, your question is not clear for me... for building multiple drivers with a common core/library module, you can find an example in isa/sb directory. there snd-sb-common is shared among several different top-level modules. (usually, the common module is named snd-xxx-lib, though.) 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] Prodigy 7.1 driver update [snd-ice1724]
Hi, Takashi Iwai wrote: Finally there is some misconception in the aureon prodigy drivers: the codec chip does not have a Master control as it appears at the mixer. Instead the master control just updates the 8 volume controls of the individual DAC at the same time. Probably the best way is to add a virtual master control (ie that we update the volumes of the dac with master attenuation + specific channel attenuation ). well, such a thing should be done on user-space rather than on kernel. let's postpone this until the new highlevel mixer functions become available. That's fine if it can be done in user space but this creates a problem with the mixer right now. Changing the master volume does not update all the DAC volumes as it should and you can be in the situation where Master is100% and all other volumes are 0, yet the playback is done in maximum volume at all channels. Maybe the driver should update all channel volumes on a master update. As I wrote some days ago, the default buffer/period rates that alsarecord uses at 44.1KHz and lower sampling , locks hard the kernel. Have no idea what is it/how to fix it whatsoever. hmm, could be the mismatch of cristal rate? i don't find out the critical path in the driver yet. No idea about that and how to debug it.. The driver still locks the kernel using arecord and default parameters at 44.1Khz but not at higher sample rates. I attached the PCM setup that locks the machine hard. It seems that the driver manages to record a few periods and then locks. Maybe the reason is the funny period buffer sizes (5513??) that appear at the pcm setup. As I understand the situation it is a (minor) problem with the ice1724 driver. Apostolis Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 44000 Hz, Stereo Hardware PCM card 0 'Audiotrak Prodigy 7.1' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S32_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 24 buffer_size : 22050 period_size : 5513 period_time : 125011 tick_time: 1 tstamp_mode : NONE period_step : 1 sleep_min: 0 avail_min: 5513 xfer_align : 5513 start_threshold : 1 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1445068800 Aborted by signal Interrupt...
Re: [Alsa-devel] Re: [PATCH]against cvs: us122 support in snd-usb-us428
On Mon, Nov 24, 2003 at 11:14:02PM +0100, Martin Langer wrote: On Mon, Nov 24, 2003 at 09:50:32PM +0100, Werner Schweer wrote: On Monday 24 November 2003 14:37, Karsten Wiese wrote: Hi, would you please give this a try an your us122s? I integrated Martins stuff into mine. us428 still works here. besides patching you'll need to copy the attached header into alsa-driver/usb/us428. you'll probaply also still need Martin's patched usx2yloader infrastructure files. it works! Tested with US-122: audio recording/play, midi play Same here. No problems. Everything works fine. And this fix will show the correct USB ID in /proc/asound/cards in the future. Thanks! martin --- usbus428.c.ORIGINAL Mon Nov 24 22:51:07 2003 +++ usbus428.cMon Nov 24 22:41:17 2003 @@ -255,7 +255,7 @@ sprintf(card-shortname, TASCAM NAME_ALLCAPS); sprintf(card-longname, %s (%x:%x if %d at %03d/%03d), card-shortname, - snd_usX2Y_usb_id_table[0].idVendor, snd_usX2Y_usb_id_table[0].idProduct, + device-descriptor.idVendor, device-descriptor.idProduct, 0,//us428(card)-usbmidi.ifnum, usX2Y(card)-chip.dev-bus-busnum, usX2Y(card)-chip.dev-devnum ); US122 support seems to be ok in pre3, but this patch wasn't committed. martin --- 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
[Alsa-devel] Soundcard Matrix: SEKD - Marian
Hi I wanted to propose a change in the alsa soundcard Matrix: The Company known as SEK'D was acquired by Magix and took down its audio hardware product line. The Interfaces are now sold by SEK'Ds former production company called MARIAN: ww.marian.de this results in a name change for the SEK'D Siena, which is now called Marc 8 Midi to fit into the marian product line. Similarly, all the other SEK'D cards, namely the ARC and Prodif Series are now sold by Marian keeping their old name. Also I wanted to provide additional information about the Marc 8 Midi (SEK'D Siena): the Card uses 4 AKM AK4524 Converters, there is an PLX PCI 9050 target chip on there, 3 memory chips (2 by EliteMT and one by Winbond) and a Xilinx Spartan FPGA. These are the main components I could make out. I hope that is enough information for you to replace that question mark in the Siena row, and maybe even for a skilled person to write a driver ;-). Are there similar cards with existing alsa drivers? Thank You Andreas --- 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] Oops still present in lastest CVS/nm256
Takashi Iwai writes:
At Tue, 25 Nov 2003 12:38:59 -0500,
David Ronis wrote:
I've posted this problem before, and the oops reported below seems to
be the same one.
I just CVS updated and rebuilt in all alsa-* directories. Aplay
sigseg's and I get an oops. The first time I tried lead to a hard
lockup. After rebooting, all I got was the oops. I'm using the nm256
driver on a Sony Z505S viao notebook with 2.4.22 of the kernel (with
lowlatency and preemptive patches applied). [The usual kernal driver
works fine and I have it configured to build as a module].
what about the kernel without preemptive?
i remember this kind of oops, but it happend e.g. when alsa-driver and
alsa-kernel versions are not synced, or linux kernel tree doesn't
match with the actual one, etc.
i don't think it's specific to nm256 driver.
OK, I've just done the following:
1. Deleted my entire linux and alsa trees.
2. Loaded a fresh copy of linux-2.4.22
3. uploaded the current CVS of the alsa tree (all subdirectories).
4. Applied the low-latency kernel patch, but not the preemptive one.
5. built and installed the kernel and modules.
6. built and installed alsa.
I rebooted, moved my no-alsa modules.conf and put in the alsa
one, ran depmod -a, and finally aplay. The system locked up, no oops
on the first try.
I did a cold reboot, with the alsa-modules.conf in place of course,
and now aplay doesn't die!
However, my sound programs don't seem to work. For example, zinf
complains about:
ALSA lib pcm_hw.c:1142:(_snd_pcm_hw_open) Invalid value for card if I
use the alsa plugin, while if I use the regular one, I get garbled
sound.
rplay also results in sound, but it's garbled;
In part, the sound seems too slow with some sort of warble or echo.
Could this be related to the lack of preemptive? I'll rebuild with
the preemptive patch applied and preemptive activated, once I hear
from you.
This is progress, I think.
Here's what's in my .alsarc file:
pcm.nm256 {
type hw
card 0
}
ctl.nm256 {
type hw
card 0
}
David
Also for what it's worth, here is my .config file for linux (I don't
think it's changed, at least not by me, since I last had Alsa working
on this machine):
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# Processor type and features
#
CONFIG_LOLAT=y
CONFIG_LOLAT_SYSCTL=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_F00F_WORKS_OK=y
CONFIG_X86_MCE=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_HIGHMEM is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_TSC_DISABLE is not set
CONFIG_X86_TSC=y
#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y
# CONFIG_TCIC is not set
CONFIG_I82092=y
CONFIG_I82365=y
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y
#
# ACPI Support
#
# CONFIG_ACPI is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
[Alsa-devel] Delta 1010 - noisy analog capture at 96 and 88kHz
A couple of months ago I replaced an M-Audio Delta66 with a Delta1010 (not LT) in my system. The Delta66 works flawlessly. The Delta1010 is OK on playback at all sample rates. Analog capture is OK at 44.1 and 48 kHz sample rates. However, at 96kHz the noise level on analog capture is very high, about -30dBfs. At 88kHz it drops to about -35dBfs. The audio is clear and undistorted, but sounds as if a pink noise generator is summed in as well. This is not a dropped sample, clicking, stuttering problem. No xruns are reported. In fact, the problem is audible/measurable by just routing the inputs directly to the outputs with via the on-board mixer/router controlled by envy24control -- no host software (e.g., ecasound, arecord) needs to be running. I wrote to M-Audio Tech support. They advised me to try it under Windows with their drivers. I did this and it worked flawlessly. I noticed that under Windows when I switched from a high sample rate (88.2 or 96) to a low sample rate (48 or 44.1) or the reverse (low to high) there was a loud click on the audio, as if something was being reset. Switching from low to low or high to high did not produce a click. Under ALSA no click is heard, just the change in the noise level. I'm running ALSA 0.9.8 on Planet CCRMA Red Hat 9. [EMAIL PROTECTED] tmp]# uname -a Linux blumlein 2.4.22-6.ll.rh90 #1 Wed Sep 10 15:43:57 PDT 2003 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] tmp]# cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 0.9.8. Compiled on Oct 28 2003 for kernel 2.4.22-6.ll.rh90 with versioned symbols. I've captured audio clips at 44.1, 48, 88.2, 96 and placed them at http://www.ai.sri.com/ajh/audio/delta-1010-noise/ This directory includes the raw output of board, 12-channels of 32-bit samples, as well as 2-channel 16-bit files of the first two channels, and OGG encoded versions of the last files. The capture and conversion was done by the script test.csh. I also tar'ed the contents of /proc/asound in proc-asound.tar, the wall paper from that shell is in proc-tar-shell, for reference. Any help or insight would be greatly appreciated. Thanks... Aaron Heller [EMAIL PROTECTED] Menlo Park, CA --- 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
[Alsa-devel] error return codes from alsa-lib
at what point, if any, did alsa-lib start returning positive EFOO values (e.g. EBUSY) rather than -EBUSY? --p --- 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
[Alsa-devel] ALSA 1.0.0pre3 release
Hi, right now the ALSA 1.0.0pre3 packages are released. In this version, alsa-tools package was divided to two several ones, alsa-tools and alsa-firmware. The latter contains only the firmware binary files required by loader programs in alsa-tools package. Please test them if you have a board requiring the loader (hdsp, mixart, vx, usx2y). Especially, HDSP users, please test and report whether it works, since the hdsploader was modified to load the files dynamically. Changes - usb-audio driver supports async unlinking. On 2.6 kernels, it's enabled as default, but on older kenrels, it's disabled to avoid a serious usb-uhci bug. If you have another controller, please try the module option async_unlink=1. - hdsp driver update (including H9652 bugfixes). - support of more Tascam USxxx devices. - Audiotrak Prodigy bugfixes. - fixed noise on vx222 with 24bit mode. - complation fixes on alsa-drivers. The 2.2 kernel is still not tested well. If you can test it, please let us know. - fixed CM8738-MC6 5.1 alias. - alsaconf fix for RH, Fedora and Mandrake. - hdsp* tools updates. compilation fixes. -- Takashi Iwai [EMAIL PROTECTED]ALSA Developer - www.alsa-project.org --- 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] ALSA 1.0.0pre3 release
On Tue, 2003-11-25 at 20:04, Takashi Iwai wrote: Hi, right now the ALSA 1.0.0pre3 packages are released. In this version, alsa-tools package was divided to two several ones, alsa-tools and alsa-firmware. The latter contains only the firmware binary files required by loader programs in alsa-tools package. Please test them if you have a board requiring the loader (hdsp, mixart, vx, usx2y). Especially, HDSP users, please test and report whether it works, since the hdsploader was modified to load the files dynamically. mmap'ed sound with the cs46xx driver seems to be broken, every other half second the sound is muted. Non-mmap'ed sound plays normally. This is under 2.6.0-test9-mm5. The version included in test9-mm5 works as expected (there was some patches in mm5 against ALSA, but applying those to 1.0.0pre3 made no difference for this particular problem). -- Ronny V. Vindenes [EMAIL PROTECTED] --- 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
