- Alsa-devel - mailman.alsa-project.org

[alsa-devel] Noise on rear speaker when switching from 2.0 to 5.1 sound
by Felix Rauscher 07 Aug '07

07 Aug '07

Hello, I have a Hercules Muse 5.1 DVD (C-Media PCI CMI8738-MC6). I have a problem when a running xine (e.g xineliboutput from vdr) switches from 2.0 to 5.1 output. Then the sound quality of the rear speakers is terrible. There is a noise on the rear speakers. If I start the xineliboutput-client when vdr already plays a programme with a 5.1 sound track, the quality is ok. It looks like the switching between 2.0 to 5.1 is a problem. Thank you for your help! Felix

2 2

Re: [alsa-devel] SOLVED Re: snd_pcm_hw_params_set_format fails with invalid argument
by stan 07 Aug '07

07 Aug '07

I sent this directly to Takashi by mistake. I could have sworn I saw the list in the to field but I must be mistaken. Here it is for the list. On Tue, 7 Aug 2007 08:02:42 -0700 stan <stanl(a)cox.net> wrote: > On Tue, 07 Aug 2007 15:38:40 +0200 > Takashi Iwai <tiwai(a)suse.de> wrote: > > > At Mon, 6 Aug 2007 09:22:01 -0700, > > stan wrote: > > > > > > On Mon, 6 Aug 2007 09:04:57 -0700 > > > stan <stanl(a)cox.net> wrote: > > > > > > > I downloaded the hg alsa-lib snapshot of July 14, 2007, compiled > > > > it, (on Fedora 7 you will have to make a link to compile, > > > > cd /usr/include > > > > ln -s python2.5 python) > > > > and linked my program against it. It works again so the issue > > > > has been fixed in the latest version of alsa lib. Any estimate > > > > of when this version will be released for public consumption? > > > > My app is dead in the water with the current version of alsa, so > > > > anyone trying to use it will have a terrible user > > > > experience. :-( I want to give some indication of when people > > > > can expect it to start working again. In the meantime I'll > > > > create instructions on how to install the hg version to > > > > usr/local and change the library linking. > > > > > > > > Thanks. > > > > > > > For anyone interested, these are the formats that fail in 1.0.14 > > > final > > > > > > Value of last format 43 > > > test of sample format 14 failed (Invalid argument) > > > test of sample format 15 failed (Invalid argument) > > > test of sample format 16 failed (Invalid argument) > > > test of sample format 17 failed (Invalid argument) > > > test of sample format 18 failed (Invalid argument) > > > test of sample format 19 failed (Invalid argument) > > > test of sample format 23 failed (Invalid argument) > > > test of sample format 24 failed (Invalid argument) > > > test of sample format 25 failed (Invalid argument) > > > test of sample format 26 failed (Invalid argument) > > > test of sample format 27 failed (Invalid argument) > > > test of sample format 28 failed (Invalid argument) > > > test of sample format 29 failed (Invalid argument) > > > test of sample format 30 failed (Invalid argument) > > > test of sample format 31 failed (Invalid argument) > > > Format returned (0) > > > > > > > > > and these are the formats that fail in the hg version. > > > > > > Value of last format 43 > > > test of sample format 18 failed (Invalid argument) > > > test of sample format 19 failed (Invalid argument) > > > test of sample format 23 failed (Invalid argument) > > > test of sample format 24 failed (Invalid argument) > > > test of sample format 25 failed (Invalid argument) > > > test of sample format 26 failed (Invalid argument) > > > test of sample format 27 failed (Invalid argument) > > > test of sample format 28 failed (Invalid argument) > > > test of sample format 29 failed (Invalid argument) > > > test of sample format 30 failed (Invalid argument) > > > test of sample format 31 failed (Invalid argument) > > > Format returned (16) > > > > Could you give me the simple test case for checking the same thing > > on my system? > > > > > > thanks, > > > > Takashi > > They are attached as file test_case.c and shell script mktest. > > Running ./mktest should generate an executable named test_case. > Running that should generate the above output. > >

1 1

[alsa-devel] snd_pcm_hw_params_set_format fails with invalid argument
by stan 07 Aug '07

07 Aug '07

Fedora 7 upgraded alsa to 1.0.14 from RC3. I was going to test the default device sound for my prior problem (as requested by Takashi weeks ago). Unfortunately when I try to run my app it won't start. The snd_pcm_hw_params_set_format fails when I try to use it as follows. err = snd_pcm_hw_params_set_access (alsa_dev, hw_params, ND_PCM_ACCESS_RW_INTERLEAVED); if (err < 0) { fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err)) ; goto catch_error ; } ; err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_FLOAT64_LE); //err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_S32_LE); if (err < 0) { fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err)) ; goto catch_error ; } ; cannot set sample format (Invalid argument) It compiles cleanly. When I replace the SND_PCM_FORMAT_FLOAT64_LE with the S32_LE, it sets it, but of course the sound is garbage as it is still receiving doubles. This code worked fine under RC3. Is there some change that occurred in the step from 1.0.14.rc3 to 1.0.14 that would explain the above and suggest a fix? Thank you. $ uname -r 2.6.22.1-41.fc7 $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC). $ ls /proc/asound/card0 ice1724 id oss_mixer pcm0c pcm0p pcm1p pcm2p

2 4

[alsa-devel] HDA: Add support for Acer Aspire laptops.
by Tobin Davis 07 Aug '07

07 Aug '07

This patch adds support for some Acer Aspire systems. Signed off by Tobin Davis <tdavis(a)dsl-only.net> I was actually sent this patch by someone on IRC. They approved for it to be submitted, and I don't see anything in the code to cause it to be kept out.

2 1

[alsa-devel] HDA: Add more Dell systems
by Tobin Davis 07 Aug '07

07 Aug '07

This patch adds support for Dell E520 and a couple of other 965 based systems. Signed off by Tobin Davis <tdavis(a)dsl-only.net> On a side note, I start back to work tomorrow, getting paid to do these patches (well, sort of).

2 1

[alsa-devel] Accessing alsa device in kernel space.
by Vasily Khoruzhick 07 Aug '07

07 Aug '07

Hi, how to access to alsa device from kernel space? I want to create driver for virtual soundcard, that will perform mixing and rate converting in kernelspace, and put result in real hardware. But I found no documentation how to open alsa device in kernel space :( Best regards, Vasily.

2 3

[alsa-devel] Some functionality of ice1724 broken between 1.0.14.RC1 and 1.0.14.RC3
by stan 06 Aug '07

06 Aug '07

Hi, This is going to be fairly long because of the explanations needed, but there are three problems I've found on my Revolution 5.1 between Alsa 1.0.14.RC1 and 1.0.14.RC3. 1. Support for high sample rates 96000 and 192000 was lost. 2. Sound distortion at high sound frequencies was introduced. 3. The maximum buffer size seems too small for high sample rates (not related to release candidate). Overview On Fedora 6 the alsa version is 1.0.14.RC1. Using that version, my application can use the high frequencies and there is no distortion introduced at high frequencies. On Fedora 7 the alsa version is 1.0.14.RC3. I can't use the high frequencies on the Revolution 5.1 and there is distortion introduced into the sound at high frequencies. In investigating this I noticed that the maximum buffer sizes seem small. 1. Here is the output from my app on Fedora 6 at 192000. (1.0.14.RC1) This works great! Minimum channels (1) Maximum channels (10000) Minimum rate (4000) Direction = 0 Maximum rate (4294967295) Direction = -1 Minimum period_time (10) Direction = 1 Maximum period_time (2048000) Direction = 0 Minimum period_size (0) Direction = 1 Maximum period_size (4294967295) Direction = -1 Minimum periods (0) Direction = 1 Maximum periods (4294967295) Direction = 0 Minimum buffer_time (1) Direction = 0 Maximum buffer_time (4294967295) Direction = 0 Minimum buffer_size (1) Maximum buffer_size (4294967294) Minimum tick_time (1000) Direction = 0 Maximum tick_time (1000) Direction = 0 Actual rate (192000) Direction = 0 Actual channels (2) Actual period_size (8) Direction = 0 Actual buffer_size (8192) <--- notice that this is reasonable Here is the output from my app on Fedora 7 at 192000. (1.0.14.RC3) This aborts while setting the hardware parameters with invalid argument. Minimum channels (1) Maximum channels (10000) Minimum rate (4000) Direction = 0 Maximum rate (4294967295) Direction = -1 Rate (48000) Direction = -1 Result = 0 <-- from test rate Rate (96000) Direction = -1 Result = 0 Rate (192000) Direction = -1 Result = 0 <-- maximum for card hw Rate (384000) Direction = -1 Result = 0 <-- accepts invalid 384000 Minimum period_time (21333) Direction = 1 <-- seems strange the same Maximum period_time (21334) Direction = -1 Minimum period_size (85) Direction = 1 Maximum period_size (91628833) Direction = -1 Minimum periods (0) Direction = 1 Maximum periods (17247242) Direction = -1 Minimum buffer_time (1) Direction = 0 Maximum buffer_time (4294967295) Direction = 0 Minimum buffer_size (170) Maximum buffer_size (1466015503) Minimum tick_time (0) Direction = 0 Maximum tick_time (4294967295) Direction = 0 Actual rate (192000) Direction = 0 Actual channels (2) Actual buffer_time (341333) Direction = 1 Actual buffer_size (65536) Actual buffer_size (65536) Actual period_time (21333) Direction = 1 Actual period_size (807872295) Direction = 1 <--- Note invalid period size Actual periods (21333) Direction = 1 cannot set parameters (Invalid argument) Could not open the sound device The two are on the same hardware, just different OS versions. While investigating I switched from using size to time as the allocation mechanism without any effect (using the sample from pcm.c on alsa site). I did a diff on the ice1724.c driver (attached below) and noticed that there was a lot of cleanup done by making the structs and arrays of structs const. Could that possibly cause this problem by not allowing calculated values to be set? Don't know. 44100 and 48000 work. I installed the alsa-debuginfo package to try to get a handle on this in gdb. But with the extreme indirection in alsa in order to deal with all the options and the compiler optimization, gdb left my head spinning so I thought I would ask here before going any further. Can you think of an explanation for this behavior? Can you fix it? 2. I ran a frequency loudness test that is part of the app. It drops the frequency at 5 seconds intervals from 20 KHz to 5 Hz alternating. On Fedora 6 with 1.0.14.RC1 it works as expected. When above my hearing range I hear silence. When it gets to frequencies I can hear the sound is pure. On Fedora 7, this same app produces noise at frequencies I can't hear. This behavior is the same as the behavior I noticed with my emu10k1, ca0106 and CK8S sound cards on 1.0.14.RC1 as well as 1.0.14.RC3. I previously had ascribed this to bad/low quality sound chips; now I'm not so sure. In terms of sound quality the Rev 5.1 ranks well. See the link http://compreviews.about.com/od/multimedia/tp/SoundCards.htm Exact same hardware produces different sound. Can't explain it. Can you? Can you fix it? 3. While looking at the ice1724.c code I noticed that the maximum buffer size is 2**18. This seems small for an application today. I'm producing sound at 192000 frames per second (admittedly overkill though I like very smooth sound) using stereo doubles (16 bytes per frame). The maximum buffer size is only a fraction of my per second byte rate. Could you increase this? Discussion. The app is a binaural / chronaural beat generator and is on sourceforge at http://sourceforge.net/projects/discord/ so you can download and run the tests yourself (about a meg). You will need libsndfile and libsamplerate installed to compile it. The version there won't have the conversion to time based allocation as I won't release that until this issue is resolved. To change the rate you change the -r option in the script file high_noon.discord (-r 192000 or --rate=192000). The run command to use is "./discord high_noon.discord". For issue 2 you have to run "./discord frequency_loudness_test.discord". Again change the rate using the -r option (-r 192000 or -r 96000 fail). The open_alsa function starts at around line 5610 in discord.c if you want to play around with the initialization. I basically cloned it from the libsndfile samples. If you aren't familiar with binaural or chronaural beats you can search for "binaural beat" or "brain wave entrainment" and find more than you probably want to know. :-) Thanks for any help.

3 5

Re: [alsa-devel] PROBLEM: snd-au8830: dead after software suspend
by Gert Robben 06 Aug '07

06 Aug '07

>>> Have you reported this to the ALSA people? >> No, I thought this might as well be something for PCI or PM people, and >> I expected some ALSA people are also reading this list. >> If not, where else should I report this exactly? > alsa-devel [...] the author of the driver Done (original message below). Thanks again :) Gert Robben wrote: > After a suspend-resume cycle (using Suspend2), my sound card doesn't > work anymore. It works again after reloading the module. > > dmesg, initial boot: >> Linux version 2.6.22-ck1 > ----8<---- >> PCI driver au8830 lacks driver specific resume support. > > dmesg, after resume, trying to use the card: >> vortex: ac97 codec stuck busy > > Thanks for any help! > > Gert Robben

3 4

[alsa-devel] a newbie overwhelmed with this API
by Adam Seychell 06 Aug '07

06 Aug '07

I'm writing simple audio application and I have successfully used the DirectSound API under Windows. Now I'm looking at porting to Linux using ALSA. I have tried reading the online ALSA API documentation, but it seems too early in development and insufficient compared what one can learn reading Microsoft's DirectX SDK documentation. Excuse my ignorance for a minute, but the API seems quite large compared to DirectSound and so I'm wondering if there is good reason why so many functions exists ? Was there an early design decision not to write ALSA in C++ ? I would like to help out with documentation but of course I thats impossible for someone who is a complete novice to the ALSA project. I know that writing good documentation takes a lot of hard work, especially for software developers who spend enough time on coding. Its an unfortunate paradox among all open source projects. Software developers who posses the knowledge can't readily communicate it to potential volunteer documentation writers in an open source environment. Adam

2 1

[alsa-devel] [PATCH] au88x0: mem leak fix in snd_vortex_create()
by Jesper Juhl 06 Aug '07

06 Aug '07

Hi, In sound/pci/au88x0/au88x0.c::snd_vortex_create() : The Coverity checker found that if we allocate storage for 'chip' but then leave via the regions_out: label, then we end up leaking the storage allocated for 'chip'. I believe simply freeing 'chip' before the "return err;" line is all we need to fix this, but please double-check me :) Signed-off-by: Jesper Juhl <jesper.juhl(a)gmail.com> --- diff --git a/sound/pci/au88x0/au88x0.c b/sound/pci/au88x0/au88x0.c index 5ec1b6f..f70286a 100644 --- a/sound/pci/au88x0/au88x0.c +++ b/sound/pci/au88x0/au88x0.c @@ -232,6 +232,7 @@ snd_vortex_create(struct snd_card *card, struct pci_dev *pci, vortex_t ** rchip) pci_disable_device(chip->pci_dev); //FIXME: this not the right place to unregister the gameport vortex_gameport_unregister(chip); + kfree(chip); return err; }

3 2