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

[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

Re: [alsa-devel] [Alsa-user] Newbie question - cannot get sound to work in Ubuntu
by Nigel Henry 07 Mar '08

07 Mar '08

On Wednesday 05 March 2008 23:48, Peter Toye wrote: > Nigel, > > Thanks. My comments are below. > > Best regards, > > Peter > mailto:alsa@ptoye.com > www.ptoye.com > > ------------------------- > > Tuesday, March 4, 2008, 6:43:43 PM, you wrote: > > Hi Peter. I've spent most of the afternoon (as I have nothing better to > > do) googling your problem, and there are a few things you can try. First > > though, do you have a live cd of Gutsy Gibbon, or Knoppix that you can > > bootup with, and see if you have the sounds working? > > That's very kind of you to take so much time. > > I booted up from a live Gutsy Gibbon CD (the one I used to create my > system) and it's quite interesting. Typing "alsamixer" in a terminal > session brings up the mixer OK! But with a seriously confusing set of > controls, only some of which seem to have much connection with the sound > card. And the "line in" column in the "capture" view doesn't have a fader > associated, which seems a bit odd. Maybe there's something I don't > understand here. > > And I can use the GNOME utilities to record and play back. Didn't have time > to try the command-line versions. Won't have time until Friday at the > earliest. > > > Now moving on to my googling stuff. > lspci -v output: > 00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev > 07) Subsystem: Creative Labs CT4830 SBLive! Value > Flags: bus master, medium devsel, latency 64, IRQ 10 > I/O ports at d400 [size=32] > Capabilities: [dc] Power Management version 1 > > 00:0b.1 Input device controller: Creative Labs SB Live! Game Port (rev 07) > Subsystem: Creative Labs Gameport Joystick > Flags: bus master, medium devsel, latency 64 > I/O ports at dc00 [size=8] > Capabilities: [dc] Power Management version 1 > > Alsamixer when opened shows the default card (card0), but have a look at > > the manpages for alsamixer. I now open these in a webbrowser as > > man:alsamixer. To start alsamixer for other cards you have the -c option. > > For example, alsamixer -c0 brings up the default cards mixer settings. > > alsamixer -c1 brings up the mixer settings for card 1, and so on. > > If I type alsamixer -c0 the mixer comes up with the same options as the CD > boot (see above). I thought that -c0 was the default, but it doesn't seem > to be. Hi Peter. It's getting a bit surreal now, as typing alsamixer, is ( under normal circumstances) the same as typing alsamixer -c0. For the sake of those on the alsa-devel list I've put the error you get when just typing alsamixer as user below. Typing "alsamixer" in a terminal window gives: "alsamixer: function snd_ctl_open failed for default: No such device" Whereas typing alsamixer -c0 opens alsamixer. At least you have access to the mixer settings now, although you say that some of the controls appear to be a bit bizarre. Would you download this script from: http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh There are a bunch of options now available for the script, so after making it executable, run it as user as below. ./alsa-info.sh --with-amixer --with-alsactl --with-configs The script will trawl out a bunch of stuff about your sounds, and upload it to pastebin. Just post back the link to the pastebin site when you reply. Not sure about an easy Alsa guide. All the best. Nigel.

2 1

[alsa-devel] HD-audio dynamic configuration
by Takashi Iwai 07 Mar '08

07 Mar '08

Hi, time passed since the last discussion about where the HD-audio driver development to go to. I checked and tried to rework a bit the user-space configuration tool, and found out that it's really hard to keep it up to date. One of the big obstacles is that the HD-audio codecs often behave unexpectedly, in most cases, due to hardware bugs. For example, some codecs need the override of AMP caps and some needs rewrite of pin caps, etc. This is hard to catch with a sole generic code. It means, we need more or less codec-specific workarounds. Consequently, I believe it's easier to keep a little amount of codec-specific parser codes in the hda driver. This is of course hard-coded in the kernel. Then the goal is to reduce the amount of "patches" we have now for each specific device type. For this purpose, I've implemented a new feature -- allow hd-audio driver to reconfigure dynamically with additional hints. The hd-audio driver would have sysfs entries that can read/write the information dynamically and trigger the re-configuration of the parser. Right now, it's created as sysfs entries of each hwdep device, so that it can be bound to each codec chip. For example, suppose the card0 has codec#2. It corresponds to hwC0D2 device. /sys/class/sound/hwC0D2/ has the following new entries: 1. vendor_id, subsystem_id, revision_id, afg, mfg, 2. name, modelname 3. init-verbs, hints 4. reconfig, clear The files in 1 are the codec information that can be obtained from the codec chip. These are digits, and can be read *and* written. The write means the specific value will be overridden, and the driver handles as if the codec returns so. For example, if you have a new, unsupported codec chip that is compatible with others, you can change vendor_id value on the fly. The files in 2 are the strings that appear in the mixer, etc. The modelname is the model module option. This can be changed dynamically as well. The init-verbs and hints are write-only. You can pass the additional init verbs (e.g. for reprogramming the pincfg) and pass hints to the codec parser code. The hints are simply strings. Then you can write (any value) to "reconfig" to trigger the reconfiguration of the codec parser. Then all existing PCMs and mixer elements of this codec will be once removed and re-generated again with new init-verbs and hints. The "clear" is to clear the existing PCMs, mixer elements and init-verbs/hints entries. Now, the big missing piece is more clever codec parser code. Especially, the generic parser could be greatly improved with hints. A lot of works ahead, though :) For people who are interested, I put preliminary patches on my git tree here: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git For building the external modules, you'd need this build stub tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/alsa-driver-build-unsta… and run utils/setup-alsa-kernel script once (see INSTALL). The alsa-driver tarball snapshots are available at: http://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ These experimental patches are in alsa-driver-unstable-snapshot tarball. Any comments appreciated. thanks, Takashi

1 0

Re: [alsa-devel] What recommended performance for ALSA(ASoC)?
by Jin-Young Park 07 Mar '08

07 Mar '08

Thanks for your reply. Your advises are very important information for me. Because explained your target system is very similar my target system. > I would like to say ALSA will perfectly runs on your target SOC clock. > I am running it on 192MHz ARM926 core along with H.264 video decoder!!!. > BogoMIPS = 95.84. > Even I had the same glitch problem before. Following debugging tips are very helpful. I have questions about debugging tips. > Few debug steps here: > 1. Check the DMA Configuration. (Transfer size, buffer size and number of Transfers) > 2. Does your period,period bytes ,buffer size of Ringbuffer matcheswith the DMA buffer? What is your ALSA driver setting that buffer bytes, period bytes, periods? Current my driver setting values are buffer bytes(4KBytes), period bytes(2KBytes), periods(2). >Check the correct re-initilization of "period" once the buffer is full. What does meannig? I don't understand. And what is proper function for checking buffer and period? prepare,trigger,irq handler, pointer... > 3. Check the current DMA postion at the point of "pointer" callback.This should be equal to number of samples send to the PCM middle layer. > 4. As Jaroslav says disc read speed should be > (44100*2*16) for 44.1K 16bit stereo. Or else read from NFSBOOT if your SOC support Ethernet. > 5. Always test with a "sinewave" for glitchs, not with your favoritesong J Tell me recommended music for audio test. Thanks.

1 0

[alsa-devel] OSS4 X-Fi driver port to ALSA
by William Pitcock 07 Mar '08

07 Mar '08

Hi, On Feburary 1, 4Front released their XFi driver to the public. Is anyone looking into porting this? If not, I will give it a try soon enough. It seems to not require any firmware at all too. William

5 13