[Alsa-devel] [PATCH] usbaudio.c: fix for 8-bit PCM format
All AUDIO_FORMAT_PCM formats are signed, even 8 bits.
Index: alsa-kernel/usb/usbaudio.c
===
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.63
diff -u -r1.63 usbaudio.c
--- alsa-kernel/usb/usbaudio.c 20 Aug 2003 09:59:59 - 1.63
+++ alsa-kernel/usb/usbaudio.c 16 Sep 2003 06:29:00 -
@@ -2002,7 +2002,7 @@
/* check the format byte size */
switch (fmt[5]) {
case 1:
- pcm_format = SNDRV_PCM_FORMAT_U8;
+ pcm_format = SNDRV_PCM_FORMAT_S8;
break;
case 2:
pcm_format = SNDRV_PCM_FORMAT_S16_LE;
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] mips fix
Hi, On Tue, Sep 09, 2003 at 08:09:45PM +0200, Takashi Iwai wrote: At Sun, 7 Sep 2003 22:36:57 -0500, Ryan Underwood wrote: In configure.in: mips*) c_opts=-mcpu=r4600 -G 0 -mips2 -fno-pic -mno-abicalls -mlong-calls processor=mips test $CONFIG_ISA = probe CONFIG_ISA= ;; -mcpu apparently needs to be changed for latest versions of gcc, as -mcpu is no longer an option on mips architecture. ok, i tried to fix it on cvs. could you give a try? Hmm, using -DEXPORT_SYMTAB has a problem in module.h, which is included from adriver.h: #ifdef __GENKSYMS__ # define _set_ver(sym) sym # undef MODVERSIONS # define MODVERSIONS #else /* ! __GENKSYMS__ */ # if !defined(MODVERSIONS) defined(EXPORT_SYMTAB) # define _set_ver(sym) sym # include linux/modversions.h # endif #endif /* __GENKSYMS__ */ Since MODVERSIONS is not defined with the mips kernel (module versioning is disabled) and EXPORT_SYMTAB is defined, it tries to include linux/modversions.h, which doesn't exist in the mips kernel. Removing -DEXPORT_SYMTAB from Rules.make causes the build to die with: hwdep.c:501: error: syntax error before this_object_must_be_defined_as_export_objs_in_the_Makefile on the last line which exports a symbol: EXPORT_SYMBOL(snd_hwdep_new); Any ideas? I posted to debian-mips before and received no reply. -- Ryan Underwood, nemesis at icequake.net, icq=10317253 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Bug in pcm_plugin.c, function snd_pcm_plug_alloc?
I believe this is a bug: the loop in plug_alloc doesn't iterate completely through the plugin linked list. The problem with this, is that snd_pcm_plugin_alloc won't get called for every plugin in the list, and vital components of those plugins won't be initialized. The solution would be to replace the while (plugin-next/prev) lines with while (plugin), to move lines: plugin = plugin-next/prev to the spot just after if (err 0) return err; I found that the aformentioned changes fixed a problem I was having with reading from /dev/dsp. Unless I set the rate to 48000, then read() would always return 0. This was because when read_transfer iterated through the plugins, the rate conversion plugin, which had not been initialized, had the value 0 in dst_channels[0].frames. This caused the entire read call to return 0. BTW, I'm using the intel8x0 driver, and the latest 0.9.6 release of alsa-drivers. Anyone else agree that this is a bug? Or am I missing something, that requires that plug_alloc to NOT iterate completely through the list? Thanks, -Nick _ Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ANN: AudioScience driver beta 0.3 (0.9.6)
At Mon, 15 Sep 2003 15:39:04 -0700 (PDT), Eliot Blennerhassett wrote: Takashi Iwai wrote: At Sun, 14 Sep 2003 22:57:04 -0700 (PDT), Eliot Blennerhassett wrote: The latest beta ALSA driver for AudioScience sound cards is available as a patch against ALSA release 0.9.6 - download it here: any chance to get the whole things into alsa tree? Takashi, I would love to get this into the ALSA tree. How do I go about doing this? Are there changes I need to make to the code to make it acceptable? firstly, Jaroslav and I will review the patch. the patch itself looks almost ok, if the indentation follows the standard kernel style (see linux/Documentation/CondingStyle). When you say the whole thing, do you mean the ALSA part of our driver, or including our underlying HPI driver. i meant the latter, including HPI driver. since the HPI driver part is the essential part of the driver, we surely need more review for that, too. IIRC, the HPI driver is GPL, so won't it be problem, right? when the audioscience driver is promoted to the linux 2.6.0 kernel tree, it must be anyway a complete set. then putting the whole stuffs into alsa directory tree would be the easiest solution, i think. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Bug in pcm_plugin.c, function snd_pcm_plug_alloc?
Nick Hogle wrote: I believe this is a bug: the loop in plug_alloc doesn't iterate completely through the plugin linked list. The problem with this, is that snd_pcm_plugin_alloc won't get called for every plugin in the list, and vital components of those plugins won't be initialized. The solution would be to replace the while (plugin-next/prev) lines with while (plugin), to move lines: plugin = plugin-next/prev to the spot just after if (err 0) return err; I found that the aformentioned changes fixed a problem I was having with reading from /dev/dsp. Unless I set the rate to 48000, then read() would always return 0. This was because when read_transfer iterated through the plugins, the rate conversion plugin, which had not been initialized, had the value 0 in dst_channels[0].frames. This caused the entire read call to return 0. BTW, I'm using the intel8x0 driver, and the latest 0.9.6 release of alsa-drivers. Anyone else agree that this is a bug? Or am I missing something, that requires that plug_alloc to NOT iterate completely through the list? Thanks, -Nick I see the read return 0 problem sometimes with the intel8x0, but for me the problem appeared with arecord, and seemed to depend on some mixer settings. Cheers James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Bug in pcm_plugin.c, function snd_pcm_plug_alloc?
At Tue, 16 Sep 2003 02:26:43 -0700, Nick Hogle wrote: I believe this is a bug: the loop in plug_alloc doesn't iterate completely through the plugin linked list. The problem with this, is that snd_pcm_plugin_alloc won't get called for every plugin in the list, and vital components of those plugins won't be initialized. The solution would be to replace the while (plugin-next/prev) lines with while (plugin), to move lines: plugin = plugin-next/prev to the spot just after if (err 0) return err; I found that the aformentioned changes fixed a problem I was having with reading from /dev/dsp. Unless I set the rate to 48000, then read() would always return 0. This was because when read_transfer iterated through the plugins, the rate conversion plugin, which had not been initialized, had the value 0 in dst_channels[0].frames. This caused the entire read call to return 0. BTW, I'm using the intel8x0 driver, and the latest 0.9.6 release of alsa-drivers. Anyone else agree that this is a bug? Or am I missing something, that requires that plug_alloc to NOT iterate completely through the list? at least i agree that is a bug, but it's in the different place :) you don't need allocate the buffer for the last plugin because the last one will write to the recording buffer directly. the attached patch will fix this problem. Takashi plugin-rec-fix.dif Description: Binary data
Re: [Alsa-devel] PCM format restrict dilema
Takashi Iwai wrote: At Tue, 16 Sep 2003 10:19:53 -0400, Manuel Jander wrote: Hello, I have the following dilema. The Aureal Vortex DMA engine supports upto 4 hardware pages, but they have to be frame aligned. The current driver also needs them to be of the same size. To archive this, i added the following code in the pcm open function. /* Force equal size periods */ if ((err = snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS)) 0) return err; /* Force DMA 32 bit alignment */ if ((err = snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4)) 0) return err; Now PCM works correctly, but some apps, like aplay fail to play some formats, because they get their period size requirementes rejected, and they just give up instead of trying other period sizes. Since aplay uses a time based criteria for the period sizes instead of sane values, the period sizes are very odd. yes, this is a known issue. recently i've talked with Jaroslav about this theme, and we agreed that it's a design flaw of the current configurator system. The question is, should i blame aplay or try to implement some workaround in the Aureal driver ?? i fixed aplay recently to allocate the period size first. this works better than the former way (buffer - period). please try the cvs version. about the influence of this bug: AFAIK, very rare applications use the time-based period/buffer size, so this is not critical. strangely enough, aplay is an exception :) (btw, aplay has also options to specify the buffer/period sizes in frames, but the time-based values are used as default.) Takashi I help develop an application called xine. We wish to use the function: - dir=0; err = snd_pcm_hw_params_set_buffer_time_near(this-audio_fd, params, buffer_time, dir); We then try to set the period size to buffer_size / 8. I have already found out that not all audio devices like an interger amount of periods, so this can fail in some circumstances. I have two problems: - 1) Once one sets the buffer size, and then tries to set the period size near, and fails. One would think that one could then go back a try a different buffer size, but I have found this does not work. 2) The different combinations of setting period_size/time and buffer_size/time and the dependence between them seems to be very difficult to achieve for all sound cards. I want to try and aim at 8 periods per buffer. Common sense would tell me that one should be able to set the buffer size first, and then try to set the period size to buffer_size/8. But I should be able to use the set_period_size_near call so that it selects the next closest value, so that I achieve a result as close as possible to what I want. This seems to fail with the current setup on some sound cards, but works with other sound cards. Can I assume that this is a bug in alsa, or some deeper issue. Cheers James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] PCM format restrict dilema
I want to try and aim at 8 periods per buffer. Common sense would tell me that one should be able to set the buffer size first, and then try to set the period size to buffer_size/8. But I why don't you set the sizes based on frame counts, not time? i suspect you're more likely to get better results. should be able to use the set_period_size_near call so that it selects the next closest value, so that I achieve a result as close as possible to what I want. This seems to fail with the current setup on some sound cards, but works with other sound cards. i hope you handle the failure to get buffer_size/8 properly ... you need to be willing to go all the way to buffer_size/2 before concluding that you can't configure the device. --p --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] PCM format restrict dilema
Paul Davis wrote: I want to try and aim at 8 periods per buffer. Common sense would tell me that one should be able to set the buffer size first, and then try to set the period size to buffer_size/8. But I why don't you set the sizes based on frame counts, not time? i suspect you're more likely to get better results. If the api for setting based on time it present, I would expect to be able to use it. should be able to use the set_period_size_near call so that it selects the next closest value, so that I achieve a result as close as possible to what I want. This seems to fail with the current setup on some sound cards, but works with other sound cards. i hope you handle the failure to get buffer_size/8 properly ... you need to be willing to go all the way to buffer_size/2 before concluding that you can't configure the device. I would expect to be able to use the set_period_size_near with direction +1, so if period_size=buffer_size/8 did not work, the alsa-lib would automatically select the next best one, even if it is buffer_size/2, but this seems to fail as well. --p Cheers James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] PCM format restrict dilema
why don't you set the sizes based on frame counts, not time? i suspect you're more likely to get better results. If the api for setting based on time it present, I would expect to be able to use it. you can use it. but the thing is that you are probably requesting times in msecs, whereas almost all PCI audio interfaces only have periods and buffers sizes that are measured in frames. this means you will likely never get the buffer size you asked for. its kind of like asking for 3 pounds of cheese in a store that only measures in kilograms. if you're happy with the approximation that will result, go ahead. otherwise, figure it out in the correct units. otoh, for USB audio, its arguably better to use msecs. sigh :) i hope you handle the failure to get buffer_size/8 properly ... you need to be willing to go all the way to buffer_size/2 before concluding that you can't configure the device. I would expect to be able to use the set_period_size_near with direction +1, so if period_size=buffer_size/8 did not work, the alsa-lib would automatically select the next best one, even if it is buffer_size/2, but this seems to fail as well. it may be that alsa-lib considers certain distances as too great to be considered near. however, i would agree with you that it should work. on the other hand, if you ask for 8 periods/buffer *or more*, this will definitely fail on many audio interfaces, since they can only offer less. keep in mind the direction argument to set_foobar_near. --p --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] FORWARD - RME Hammerfall HDSP 9652
Natasha is having email server problems and asked me to forward this to the list. - Mark On Sun, 2003-09-14 at 09:39, Natasha Barrett wrote: For some time I have been trying to get the HDSP 9652 sound card working under LINUX (with Pd). Everything was fine in an old, slower machine. The new machine has been impossible, and no-one appears to have had the same problems as me. The closest I found was the thread from August about firmware revisions. Maybe you can suggest something. I currently have rev. 100 of the firmware. Have you tried this? Here is a list of alsa kernel versions tested and the errors they give: 1. kernel 2.4.21-1.ll-acpi 2. Alsa v 0.9.6 Result: works OK for anything between 10 minutes to 10 hours and then audio stops with input and output values equal levels. No error message is given. Audio just stops. The machine may need rebooting 10 times before audio will resume. It appears random. 1. kernel 2.4.21-1.ll-acpi 2. Alsa v 0.9.0rc6 (version that worked fine on old machine, can't run old kernel on new machine). Result: modprobe snd-hdsp seg faults. Have also tried alsa versions: 0.9.4 - made no sound at all. 0.9.5 - Made sound, but only at channel 3-7 Is it worth trying to upgrade to firmare 101? Is there anyway to do this under LINUX, or do I have to install Windows? Thanks for any suggestions. Natasha Barrett Mark who forwarded your mail experienced similar problems (though they occured at a much higher rate), and it appears using firmware 101 solved them. I also know from RME that some of the first cards from the 9652 series were defective, and had to be sent back to the manufacturer. Did you ever use the card under windows or mac os with success ? If you choose to upgrade your firmware you'll have to find a windows box for now, sorry. I'm planning to develop a linux tool to do this in the next months, but don't expect anything soon. You may also want to try the patches I posted to this list a few weeks ago. They fix a few issues with the 9652 driver, notably enabling proper operation of the matrix mixer code, and implementing the metering stuff. I have a development hdspmixer (totalmix clone) version working with this driver, feel free to email me if you need it. Thomas --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Trident problems.
Takashi Iwai [EMAIL PROTECTED] said: could you please try the attached patch? if it still doesn't solve the problem, try to increase the length of timeout in snd_trident_4d_dx_init(), e.g. end_time = jiffies + HZ * 2; it will wait for 2 seconds. try this with and without the patch. if the same problem happens, try to commend out the line return -EIO; in the same function, so that the probing proceeds even if the check fails. let's see whether the further ac97 probing works. if still fails... remove the warm reset part. Sorry for the slow reply... I tried the patch and it didn't work so I also tried combining the above fixes with and without the patch. Still no luck :( Would it be helpful to put debug messages on each line and pasting that, or should I try something else? Thanks, David --- David Parker [EMAIL PROTECTED] Neon Goat Productions http://www.neongoat.com 0xF90FFFE5 / F362 51F7 6D51 85EB AF68 75B9 D29B 1AFC F90F FFE5 --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ANN: AudioScience driver beta 0.3 (0.9.6)
Takashi Iwai wrote: any chance to get the whole things into alsa tree? Takashi, I would love to get this into the ALSA tree. How do I go about doing this? Are there changes I need to make to the code to make it acceptable? firstly, Jaroslav and I will review the patch. the patch itself looks almost ok, if the indentation follows the standard kernel style (see linux/Documentation/CondingStyle). Getting asihpi.c into standard style should not be too much work. When you say the whole thing, do you mean the ALSA part of our driver, or including our underlying HPI driver. i meant the latter, including HPI driver. since the HPI driver part is the essential part of the driver, we surely need more review for that, too. Please, go ahead... tell me the worst - I won't be surprised. IIRC, the HPI driver is GPL, so won't it be problem, right? No problem with using the code. However, it is extremely unlikely that we will redo all the HPI files to meet the CodingStandard. I have read it and it does say preferred not mandatory. If its just a matter of running them all through indent -kr -i8 then thats OK. when the audioscience driver is promoted to the linux 2.6.0 kernel tree, it must be anyway a complete set. then putting the whole stuffs into alsa directory tree would be the easiest solution, i think. Takashi Eliot Blennerhassett AudioScience Inc. -- Junk footer beyond this point. Read at your own risk. - Sign up for ICQmail at http://www.icq.com/icqmail/signup.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
