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

[alsa-devel] ICE1724 - File descriptor in bad state when capturing
by Pavel Hofman 11 Mar '08

11 Mar '08

Hi, I have most of the ESI Juli driver working, but I have hit a problem with the capture stream. I had to modify some ice1724.c code to allow redefining clock-related functions in the actual card file (Juli has a different clocking scheme), but all the DMA code is left intact, as well as the methods defining the capture stream. The ice1724 vu-meters detect input ADC data, I can hear correct sound when setting the internal mixer to H/W-In. Yet, when trying to record, I get arecord -v -D hw:0,0,0 -r 44100 -f S32_LE -c2 .... RIFF$WAVEfmt ... data arecord: pcm_read:1346: read error: File descriptor in bad state At the same time, my second Envy24-based card Prodigy192 (uses the original methods in ice1724.c) works OK, arecord gives no errors. Swapping the cards using the model parameter (to swap the /dev/snd/pcmCXDXc device file) makes no difference. Thank you for any hints of where I should focus my attention to. I am not attaching the patches, as they are rather complicated. If you find that important, I will send the preliminary version. Pavel Hofman.

3 4

[alsa-devel] edirol m100fx
by J Brumbagh 11 Mar '08

11 Mar '08

I saw a post on the soundcard list to contact you if I have a Roland/Edirol M-100fx 10 channel mixer. I do have one and I would like to help out in anyway I can. The post seems to have been from Clemens Ladisch but I'm not sure if that matters. Please let me know how I can be of assistance. On another note I also have an internal sound card lspci lists as an ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)" This card has a headphone jack that seconds as a MiniTOSlink fiber optic jack. The sound card works fine however the fiber optic doesn't work. I think I do have windows drivers for this device on the OEM XP installation cd I have. I would greatly like to have this working properly and am also willing to help with the development. Thanks, Justin ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

2 1

[alsa-devel] What does fifo_size mean in struct snd_pcm_hardware?
by Jin-Young Park 11 Mar '08

11 Mar '08

Hello. Struct snd_pcm_hardware have fifo_size field. The fifo place in audio interface(AC97, I2S) or in ALSA architecture? What does it meaning? I could not find it that related implementation in ALSA source code. Thanks.

2 1

Re: [alsa-devel] X-Fi support in ALSA.
by Spike 11 Mar '08

11 Mar '08

> Hi, > > I have now had a chance to read some of the specs of the X-Fi cards. > aka. emu20k1. > It turns out that some of the X-Fi cards have a compatibility mode. > By default, they boot up in compatibility mode. > The interesting point is that this "compatibility mode" is in fact > the intel-HD standard so could use the intel-hda driver. > For one X-Fi card with IDs: > Device 1102:0009 Subsystem: 1102:0010 > works a bit with the ALSA hda-intel driver. > So far, the off the shelf hda-intel driver, with simple PCIs > adjustment, works for the above card, but only sound capture works so > far, so probably some quirk would be needed. > This compatibility mode works with the Windows Vista UAA drivers. > > Not all X-Fi cards support with compatibility mode. For example, any > card with (after a cold boot into Linux) > Device 1102:0005 Subsystem: xxxx:xxxx > will be X-Fi only. > > With regard to actual full X-Fi support, I am still in the progress of > creating a GPL emu20k1.h file, that is the first step towards an > snd-emu20k1 native ALSA driver. > > James Hello, That first ID is an X-Fi Xtreme Audio PCIe (CA0110-IBG) is it not? Not a real EMU20K1 based X-Fi, fully software driven, and from what I read its just a PCIe variation of the old CA0106. This thing will probably work with snd-ca0106 if creative kept to their old tactics regarding their low end X-Fi products. As for supporting the real X-Fi's, this is great news, its been a very longtime coming. One just has to question Creative's motives behind finally releasing the datasheets out of the blue like that after more than 2 years of trying to get them. Are these sheets under an NDA? Full support of an X-Fi will probably also need a firmware loader. If the PCIe CA0110-IBG doesn't share any common traits with a full blown EMU20K1, then I think the real X-Fi's should be focused on first as many more people are going to have these real X-Fi's that are useless to them at the moment, (about 3 years remember). I'll be around to help test code and can try anything you will require to help out supporting a real X-Fi card. 02:08.0 Multimedia audio controller: Creative Labs SB X-Fi [1102:0005] Subsystem: Unknown device 415a:0034 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at a400 [size=32] Memory at efc00000 (64-bit, non-prefetchable) [size=2M] Memory at e8000000 (64-bit, non-prefetchable) [size=64M] Bren

2 1

[alsa-devel] Problems with nonblocking capture every 20ms
by Johannes Dohmen 10 Mar '08

10 Mar '08

Hi there, With a sampling rate of 8000 I want to capture every 20ms a chunk (160 frames) of data from the soundcard. That works ok, but every ~5 seconds I get a EGAIN from snd_pcm_readi(). I understand that this is not an error but a notification that the sound card is not ready and should be asked again for data later on. Probably the easiest way to get rid of the EGAINs would be to use blocking IO, which I would prefer, but I have timing restrictions and snd_pcm_readi() has no sort of timeout (which I could see at least). Additional Information: The reason for me the read from the sound card every 20ms is, that I need to do so for my voip-app (rtp&sip) which needs to send 160 frames every 20ms. The calculation is: PacketsPerSecond=50 SampleRate=8000 FramesPerPacket=8000/50=160 Wait=1000ms/50=20ms I know that EAGAINs might occur and I'm confident that I handle them ok on the RTP-Level (which is to notify the other side which then plays empty samples). Still I would guess, that I could receive much less EGAINs if I would setup the sound card better. If played around with the period time and size and buffer time and size, but honestly I did not really get the point of them and try&error has not helped me either. Thanks in advance & greetings from Germany Johannes

3 2

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha
by Rene Herman 10 Mar '08

10 Mar '08

On 09-03-08 16:34, Ivan Kokshaysky wrote: > On Fri, Mar 07, 2008 at 09:58:28PM -0600, Bob Tracy wrote: >> (1) Using the sox-based "play" command to play a short ".wav" file >> results in the file being played approx. 1.5 times, i.e., it plays >> all the way through, then restarts from the beginning and quits >> somewhere in the middle of the second playback. At least the >> sound doesn't seem distorted... >> >> (2) Using "mpg123" results in silence at first, then after about 30 >> seconds, a tight loop of random repeating sound (doesn't sound like >> part of the mp3 file, but it's probably derived from it :-)) until >> the process is forcibly killed. > > Sounds like a DMA screwup. However, I'm pretty sure that it's not a > generic ALSA problem with ISA DMA, as my good old GUS MAX still works > perfectly on lx164 (machine that is very similar to your miata) as > I checked yesterday with patched 2.6.25-rc4. :-) > >> I have to hit <ctrl>C twice to interrupt playback. >> >> /proc/asound/cards looks normal: >> >> 0 [ES1888 ]: ES1888 - ESS AudioDrive ES1888 >> ESS AudioDrive ES1888 at 0x220, irq 5, dma1 1, dma2 5 > > I wonder if it still works on x86 - perhaps you ought to ask ALSA folks. > I'll search my machine room next week - I recall that there were a dozen > of old ISA soundcards, maybe there is some es18xx stuff, but chances > are slim... Missed the original mssage, adding alsa-devel. I have a few dozen es18xx's cards but no Alpha's. Am compiling a 2.6.25-rc4 onto an x86 test box now. Rene.

1 0

[alsa-devel] [patch] dmix skipping first set of samples
by Mike Gorse 10 Mar '08

10 Mar '08

There was a change in alsa-lib 1.0.16 which looks like it was designed to make dmix skip samples in the case of underruns, but it causes the first sample to be skipped since dmix->slave_hw_ptr == dmix->slave_appl_ptr. The following patch fixes this and fixes a small typo in the comment: --- src/pcm/pcm_dmix.c.orig 2008-01-18 20:00:10.000000000 -0500 +++ src/pcm/pcm_dmix.c 2008-03-09 18:01:13.000000000 -0400 @@ -311,9 +311,9 @@ if (size >= pcm->boundary / 2) size = pcm->boundary - size; - /* the slave_app_ptr can be far behing the slave_hw_ptr */ + /* the slave_app_ptr can be far behind the slave_hw_ptr */ /* reduce mixing and errors here - just skip not catched writes */ - if (dmix->slave_hw_ptr < dmix->slave_appl_ptr) + if (dmix->slave_hw_ptr <= dmix->slave_appl_ptr) slave_size = dmix->slave_appl_ptr - dmix->slave_hw_ptr; else slave_size = dmix->slave_appl_ptr + (dmix->slave_boundary - dmix->slave_hw_ptr); Thanks, -- Mike Gorse / AIM:linvortex / http://mgorse.freeshell.org --

2 1

[alsa-devel] [PATCH] hda: Reorganized DAC outputs.
by Matthew Ranostay 10 Mar '08

10 Mar '08

Changed so that internal speakers point to the Front mixer instead of Surround. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 3f01993fbc3d pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Sat Mar 08 11:08:32 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Sat Mar 08 20:37:27 2008 -0500 @@ -538,8 +538,8 @@ static struct hda_verb dell_m6_core_init /* set master volume and direct control */ { 0x1f, AC_VERB_SET_VOLUME_KNOB_CONTROL, 0xff}, /* setup audio connections */ - { 0x0a, AC_VERB_SET_CONNECT_SEL, 0x00}, - { 0x0d, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, + { 0x0a, AC_VERB_SET_CONNECT_SEL, 0x01}, { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x02}, /* setup adcs to point to mixer */ { 0x20, AC_VERB_SET_CONNECT_SEL, 0x0b},

2 1

[alsa-devel] snd-hda-intel: Fix volume-wheel and microphone on Fujitsu-Siemens Amilo M3438G
by M G 10 Mar '08

10 Mar '08

Currently the default model that gets selected on this hardware is "F1734". Using this model neither the volume-wheel nor microphone (internal or external) work. The first part of my patch changes the default model to "fujitsu", this enables the volume wheel on the left side of the laptop. The second part changes the capture settings and thus makes it possible to record from microphones. Now when capturing from the external microphone I can hear myself talking but its quite quiet. I can improve this a little by raising the capture volume, but if I raise it above 40 I can no longer record anything. Questions: Is this patch any good or is there a better way to fix my problems? Why is the recording so quiet and why can't I record with capture value above 40? Patch: diff -r c4c5e6ced12f pci/hda/patch_realtek.c --- a/pci/hda/patch_realtek.c Wed Feb 06 15:48:06 2008 +0100 +++ b/pci/hda/patch_realtek.c Wed Feb 06 15:59:28 2008 +0100 @@ -2917,7 +2917,7 @@ static struct snd_pci_quirk alc880_cfg_t SND_PCI_QUIRK(0x161f, 0x203d, "W810", ALC880_W810), SND_PCI_QUIRK(0x1695, 0x400d, "EPoX", ALC880_5ST_DIG), SND_PCI_QUIRK(0x1695, 0x4012, "EPox EP-5LDA", ALC880_5ST_DIG), - SND_PCI_QUIRK(0x1734, 0x107c, "FSC F1734", ALC880_F1734), + SND_PCI_QUIRK(0x1734, 0x107c, "FSC F1734", ALC880_FUJITSU), SND_PCI_QUIRK(0x1734, 0x10ac, "FSC", ALC880_UNIWILL), SND_PCI_QUIRK(0x1734, 0x10b0, "Fujitsu", ALC880_FUJITSU), SND_PCI_QUIRK(0x1854, 0x0018, "LG LW20", ALC880_LG_LW), @@ -3161,7 +3161,7 @@ static struct alc_config_preset alc880_p .dig_out_nid = ALC880_DIGOUT_NID, .num_channel_mode = ARRAY_SIZE(alc880_2_jack_modes), .channel_mode = alc880_2_jack_modes, - .input_mux = &alc880_capture_source, + .input_mux = &alc880_6stack_capture_source, .unsol_event = alc880_uniwill_p53_unsol_event, .init_hook = alc880_uniwill_p53_hp_automute, },

2 9

[alsa-devel] [PATCH] 2/2 alsa-python: API coverage documentation
by Aldrin Martoq 08 Mar '08

08 Mar '08

HG Log: ------- Added python coverage doc Description: ------------ This is the output of the alsa-python-coverage tool for the current HG repository. It is intented to be used by the alsa-python without the need to call the tool. Sample usage: ------------- $ grep ^STAT doc/COVERAGE $ grep ^N/A doc/COVERAGE Cheers!, -- Aldrin Martoq <amartoq(a)dcc.uchile.cl>

1 0