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

[alsa-devel] Changing the sample rate/channels of an already opened PCM stream
by Ed Schouten 19 Jun '07

19 Jun '07

Hello, I am the author of the command line music player Herrie (http://herrie.info/). For a long time folks have asked me to add support for OSS to Herrie, so this morning I decided to install Linux on a spare disk of mine (Ubuntu 7.04, FWIW) to hack on ALSA support for Herrie. After (a real lot of) hours of reading code, reading the Doxygen stuff, etc. I now have a functional ALSA output module for Herrie. It was quite hard to get it working, so I guess I owe myself a beer! ;-) Anyway, there still is one disadvantage to my module; each time I detect that a new track is going to be started that needs a different amount of channels or sample rate, I reopen the ALSA device, something that is just impossible. The reason why it's impossible: Herrie has a nifty chroot() functionality that allows users to trap the application in a certain directory. I have been trying to get the device to reset so I can change the sample rate, but for some reason, it just gets ignored. Can someone explain me how it's possible to reset the sample rate after preparing the handle? For your information, here's a link to the latest version of the source code of my ALSA module: http://g-rave.nl/gitweb?p=herrie;a=blob;f=herrie/src/audio_output_alsa.c Yours, -- Ed Schouten <ed(a)fxq.nl> WWW: http://g-rave.nl/

2 2

[alsa-devel] Writing an AT91SAM9260-EK Dumb Codec Driver
by Paul Kavan 18 Jun '07

18 Jun '07

Hello all: I am working on a driver for a dumb codec to work with the SSC as a PCM on the AT91SAM9260. I have, with the gracious help of Frank Mandarino, have the glue code written without too many problems. However, I need some guidance on getting a few things configured correctly for my codec and then getting it to compile and load correctly. For configuration, I am using the Winbond W6811. For this, I am going to use a 256kHz BCLK and an 8kHz frame. Each sample consists of 8-bit u-law PCM, MSB first. When I execute a read from the codec to the processor, I need to make the reads on the falling edge of the BCLK at each sync pulse. When executing a write from the processor to the codec I need to write on the rising edge at each sync pulse. I think I the timing correct in my driver with: cmr_div = 187; /* PCM_CLK = ~96MHz/(2*187) = 256kHz */ period = 15; /* PCM_SYNC = PCM_CLK/(2*(15+1)) = 8000Hz */ However, I am not sure how to get the following correct for my needs: #define W6811_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE) Now to making the driver once the code is done. I am relatively new to writing linux drivers. In the 6 or so that I have written, I usually cross-compile them as modules and then insmod them. I have tried that here and am getting a strange warning that I am unsure of. I have a pretty simple Makefile and when I execute it, I get: make ARCH=arm CROSS_COMPILE=arm-linux- make -C ~/Linux_Builds/linux-2.6.21.5M=/home/grhuser/Door_Access_System/Remotes/Driver/sound modules make[1]: Entering directory `/home/grhuser/Linux_Builds/linux- 2.6.21.5' CC [M] /home/grhuser/Door_Access_System/Remotes/Driver/sound/grh_ek_w6811.o Building modules, stage 2. MODPOST 1 modules WARNING: "at91_ssc_dai" [/home/grhuser/Door_Access_System/Remotes/Driver/sound/grh_ek_w6811.ko] undefined! CC /home/grhuser/Door_Access_System/Remotes/Driver/sound/grh_ek_w6811.mod.o LD [M] /home/grhuser/Door_Access_System/Remotes/Driver/sound/grh_ek_w6811.ko make[1]: Leaving directory `/home/grhuser/Linux_Builds/linux- 2.6.21.5' As you can see, I am using linux-2.6.21.5 I have ALSA checked and AT91-SoC checked in my .config file. For this attempt to build the driver, I have a separate folder than contains: at91-ssc.h and at91-pcm.h. If there is a more correct way to do this and be able to debug it, please let me know. I have attached copies of my driver. I would appreciate any and all feedback and assistance on getting this running.

2 6

[alsa-devel] .asoundrc
by Nobin Mathew 18 Jun '07

18 Jun '07

Hi, I am trying to write one .asoundrc file What i am currently doing is rate conversion My .asounrc file contains pcm.sirf3a { type rate slave { pcm "hw:0,0" rate 8000 } } I am using following command aplay -M -D sirf3a /usr/share/sounds/alsa/Side_Right.wav But it is giving me some errors aplay: set_params:909: Channels count non available Any idea why this? where I am going wrong?

2 2

[alsa-devel] [ASoC] Missing shutdown() vectors in ASoC
by Nobin Mathew 18 Jun '07

18 Jun '07

Liam, Shutdown() vectors is missing in ASoC, we need this to ensure proper shutdown of the system. * codec device */ struct snd_soc_codec_device { int (*probe)(struct platform_device *pdev); int (*remove)(struct platform_device *pdev); int (*suspend)(struct platform_device *pdev, pm_message_t state); int (*resume)(struct platform_device *pdev); }; /* SoC CPU DAI */ struct snd_soc_cpu_dai { /* DAI description */ char *name; unsigned int id; unsigned char type; /* DAI callbacks */ int (*probe)(struct platform_device *pdev); void (*remove)(struct platform_device *pdev); int (*suspend)(struct platform_device *pdev, struct snd_soc_cpu_dai *cpu_dai); int (*resume)(struct platform_device *pdev, struct snd_soc_cpu_dai *cpu_dai); unsigned int (*config_sysclk)(struct snd_soc_cpu_dai *cpu_dai, struct snd_soc_clock_info *info, unsigned int clk); /* DAI capabilities */ struct snd_soc_pcm_stream capture; struct snd_soc_pcm_stream playback; struct snd_soc_dai_cap caps; /* SoC platform interface */ struct snd_soc_platform { char *name; int (*probe)(struct platform_device *pdev); int (*remove)(struct platform_device *pdev); int (*suspend)(struct platform_device *pdev, struct snd_soc_cpu_dai *cpu_dai); int (*resume)(struct platform_device *pdev, struct snd_soc_cpu_dai *cpu_dai); /* pcm creation and destruction */ /* SoC machine */ struct snd_soc_machine { char *name; int (*probe)(struct platform_device *pdev); int (*remove)(struct platform_device *pdev); /* the pre and post PM functions are used to do any PM work before and * after the codec and DAI's do any PM work. */ int (*suspend_pre)(struct platform_device *pdev, pm_message_t state); int (*suspend_post)(struct platform_device *pdev, pm_message_t state); int (*resume_pre)(struct platform_device *pdev); int (*resume_post)(struct platform_device *pdev); Nobin Mathew

2 4

[alsa-devel] Query regarding pcm->private_data
by Pharaoh . 18 Jun '07

18 Jun '07

Hi I am reading 'Wring an alsa driver'. It says following about the private_data: You can allocate a record for the substream and store it in runtime->private_data. Usually, this is done in the open callback. Don't mix this with pcm->private_data. The pcm->private_data usually points the chip instance assigned statically at the creation of PCM, while the runtime->private_data points a dynamic data created at the PCM open callback. What does static and dynamic mean here? Apologies for this question if it sounds very novice, since my understanding is it doesn't mean static and dynamic in the usual way like stack and heap etc. Why I am being so paranoid about this has reason: In my ALSA driver I am assigning pcm->private_data = mychip, but it is NULL in the snd_pcm_attach_substream() function. I have checked my code many times and I tried with another driver which was working when tested using ALSA utils. Currently I am testing using the OSS emulation i.e. simply cat /dev/audio.

2 1

[alsa-devel] Alsa mixer interface limitations?
by Ctirad Fertr 17 Jun '07

17 Jun '07

Hello! I'm currently in phase of adding support for higher sample rates into e-mu 1212m/1820m driver. These cards have a lot of physical inputs and outputs and also a bunch of internal buses used for capture, playback and internal routing between physical inputs and outputs. Both physical I/O and internal buses are shown in alsamixer, so one can set routing easily. It's a lot of switches, anyway. The card has three modes. The standard (or "single speed") mode is the only mode currently supported in emu10k driver. It is capable of 44.1/48kHz sample rate only. If we need higher sample rates, we have to switch the card into either "double speed" (for 88.2/96kHz) or "quadruple speed" (for 176.4/192kHz) mode. The problem is that the number of inputs, outputs and especially internal buses significantly changes at higher speed modes. The reason is that internal buses are 44.1/48kHz only and thus we must use two (or four) of them per channel. Also some physical I/O ports disappear at double and quadruple speeds (e.g. ADAT has 4 channles at 96k and 2 at 192k, S/PDIF is completely disabled at 192k). The question is how to deal with that in alsamixer? IMHO the best way would be to change the number of switches in alsamixer on the fly. Unfortunatelly, I'm afraid it's impossible. Another way would be to make a particular swiches inactive, though I don't know if it is a good idea and it wold require a lot of code anyway. Any ideas? Please help! Ctirad

1 0

[alsa-devel] Got microphone working with SigmaTel STAC 9221 A1 on a Dell XPS M1210
by Eran Guendelman 17 Jun '07

17 Jun '07

I installed SuSE 10.2 on my new XPS M1210 laptop and found that the microphone was not working (headphones and internal speakers worked fine). I eventually got it working, and wanted to write an email describing how I did this. The two main important steps (which I will describe in more detail below) were: - Changing the default pin configurations ref922x_pin_configs in patch_sigmatel.c to values that were based on the windows driver's INI file but with one important tweak. - Running the driver using the "model=ref" parameter so that the above modified pin configurations are used. Note that it could be that my solution is overkill and there's actually a way to get this working with the unmodified alsa drivers... But I did not find any such solutions (e.g. I've tried setting "model=ref", "model=3stack", "model=5stack", but none of those fixed the microphone). In general, it seems that the solutions proposed on the internet to getting the SigmaTel codec working are very dependent on the exact type of system you've got... So this will likely only work for a Dell XPS M1210. Here is some more system info: "lspci -v" gives this as my audio card: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01d7 Flags: bus master, fast devsel, latency 0, IRQ 233 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) My card uses the snd_hda_intel module, and the codec type (given by "cat /proc/asound/card0/codec#0") gives this information at the top: Codec: SigmaTel STAC9221 A1 Address: 0 Vendor Id: 0x83847680 Subsystem Id: 0x102801d7 Revision Id: 0x103601 So here's what I did (taking many days and many wrong steps before arriving at this solution): - I have a dual-boot system and installed the official DELL drivers for the sound card in Windows XP. My goal was to find which INI file corresponded to my installed sound card, so I did the following: - Using Windows device manager, I looked at the properties for the SigmaTel codec driver and found that one of the property items had a string that included the substring VEN_8384&DEV_7680&SUBSYS_102801D7 - The self-extracting DELL driver extracted files into c:\dell\drivers\r122161, and in the wdm subdirectory I searched for the above string and found that the files 92xxM.INI, Sthda.ini, and sthda64.ini all contained the above string and also had the suffix =92xxM8-2.ini appended to it. This led me to deduce that the relevant file was 92xxm8-2.ini - This is an excerpt from 92xxm8-2.ini: [HKR\Settings\pin\0A] CfgDflt = dword: 0x0221121E AltCfg = hex: 20,12,11,02 Action = hex: 80,00,87,00,81,0D [HKR\Settings\pin\0B] CfgDflt = dword: 0x408103FF [HKR\Settings\pin\0C] CfgDflt = dword: 0x0281123E AltCfg = hex: 22,12,11,02,30,12,A1,02 Bias = hex: FF,04,02 Action: hex: 0A, 0C [HKR\Settings\pin\0D] CfgDflt = dword: 0x90100310 [HKR\Settings\pin\0E] CfgDflt = dword: 0x408003F1 [HKR\Settings\pin\0F] CfgDflt = dword: 0x0221122F AltCfg = hex: 21,12,11,02 Action = hex: 80,00,87,00,81,0D [HKR\Settings\pin\10] CfgDflt = dword: 0x03451340 [HKR\Settings\pin\11] CfgDflt = dword: 0x40C003F2 [HKR\Settings\pin\15] CfgDflt = dword: 0x50A003F3 [HKR\Settings\pin\1B] CfgDflt = dword: 0x405003F4 - This will be useful later... Now back to linux. - I downloaded latest alsa-driver package (version 1.0.14). - I edited alsa-kernel/pci/hda/patch_sigmatel.c, and replaced the contents of the ref922x_pin_configs array with the default pin configurations found in the INI file above WITH ONE IMPORTANT TWEAK. Specifically, this is my new array: static unsigned int ref922x_pin_configs[10] = { 0x0221121E, 0x408103FF, 0x02A1123E, 0x90100310, 0x408003F1, 0x0221122F, 0x03451340, 0x40C003F2, 0x50A003F3, 0x405003F4 }; - If you compare these numbers to the CfgDflt values from the Windows INI file above, you'll see that they match except that for the third value, instead of 0x281123E I use 0x2A1123E Here's why: I figured out that pin complex 0x0c was my microphone jack (the right-most of the three jacks in the front of my laptop). The 0x281123E configuration indicates a "Line In at Ext Front" jack... Indeed, this jack can serve as a line in or mic in or even I believe as output to rear speakers. But designating it as Line In by default seems to confuse the patch_sigmatel.c routines that set up the codec... They assume it's just a line in jack and do not mark it as potential microphone input. Changing the 8 to an A in the value designates it as "Mic at Ext Front", so the codec recognizes it as the microphone input for the card. What ends up happening is that as a microphone input, the Pin-ctls for the pin gets assigned to 0x24, whereas when it just thinks it's a Line In the Pin-ctls gets set to 0x20. Both designate an input, but the 4 in 0x24 seems to also give it a Voltage Reference Signal which I guess is important for microphone inputs. (I don't fully understand most of this stuff... I've just been reading up about the HD Audio specs over the last few days). - Build and install drivers using "./configure --with-cards=hda-intel --with-sequencer=yes; make; make install" - Make sure the snd_hda_intel gets loaded with model=ref option. You need to specify the ref model so that the pin configurations set up above are used. Of course, the right way to do this would be to make a whole new model, but I didn't bother doing that in my quick hack. Anyway, in SuSE 10.2 you can set the model through YaST, or you can manually edit /etc/modprobe.d/sound and make sure model=ref is listed as one of the options in the "options snd-hda-intel . . ." line - Reset sound drivers. (Best to just reset computer, but on SuSE 10.2 it usually works if I do "/etc/init.d/alsasound reset") - And that's basically it... In the mixer (e.g. alsamixer) it's important to make sure the Capture channel has "CAPTUR" on and that it's at a high value, and that the Mux is at its max too. It does not allow me to change "Input Source", but that's fine because the above essentially hard codes it to be Front Mic which is what I wanted. I've attached the contents of /proc/asound/card0/codec#0 in its good (mic working) state. The final path is 0x0c (mic) -> 0x12 (audio selector, stereo amp-out; Mux in the mixer) -> 0x17 (audio selector, stereo amp-in; Capture in the mixer) -> 0x06 (audio input) After searching on the internet, reading about HD Audio, and poking around the driver code, I do have a number of lingering questions I would be happy to have answered: - Why does patch_sigmatel.c "fix" mux capture levels to 2? The Mux (0x12) ends up in the path from the mic in jack to the audio in, so is it supposed to act as a Mic Boost or something? - I noticed my headphone jacks (0x0a, 0x0f) have Pin-ctls set at 0xc0 which is OUT HP (i.e. uses a low impedance amplifier for headphone output). Would it damage my sound card or speakers if I connected these jacks to powered speakers or to an audio receiver (i.e. more traditionally connected to a Line Out)? - Does the snd_hda_intel driver currently (or will it eventually) support dynamic switching so I can switch from the Mic In to Line In or to Rear Speakers Out, etc, just like in the Windows driver? - Some solutions on the internet talked about creating an .asoundrc file to get the codec working... I don't understand what that file is for and whether I need to tweak it at all... But since I have a working solution without the file I guess I'm fine? Thanks, Eran. P.S. Not subscribed, so please respond by email... Codec: SigmaTel STAC9221 A1 Address: 0 Vendor Id: 0x83847680 Subsystem Id: 0x102801d7 Revision Id: 0x103601 Default PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=1 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1 Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0x6b 0x6b] Power: 0x0 Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0x66 0x6d] Power: 0x0 Node 0x06 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x17 Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x18 Node 0x08 [Audio Output] wcaps 0x40211: Stereo Digital PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Node 0x09 [Audio Input] wcaps 0x140311: Stereo Digital PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Connection: 1 0x11 Node 0x0a [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x0221121e: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0xc0: OUT HP Connection: 1 0x02 Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x408103ff: [N/A] Line In at Ext N/A Conn = 1/8, Color = Unknown Pin-ctls: 0x20: IN Connection: 1 0x04 Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x02a1123e: [Jack] Mic at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0x24: IN Connection: 1 0x03 Node 0x0d [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x90100310: [Fixed] Speaker at Int N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x40: OUT Connection: 1 0x02 Node 0x0e [Pin Complex] wcaps 0x400081: Stereo Pincap 0x0824: IN Detect Pin Default 0x408003f1: [N/A] Line In at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x20: IN Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0837: IN OUT Detect Pin Default 0x0221122f: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0xc0: OUT HP Connection: 1 0x05 Node 0x10 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x03451340: [Jack] SPDIF Out at Ext Left Conn = Optical, Color = Black Pin-ctls: 0x40: OUT Connection: 3 0x08* 0x17 0x19 Node 0x11 [Pin Complex] wcaps 0x430681: Stereo Digital Pincap 0x0810024: IN EAPD Detect Pin Default 0x40c003f2: [N/A] SPDIF In at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Power: 0x0 Node 0x12 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x02 0x02] Connection: 7 0x0e 0x15 0x0f 0x0b 0x0c* 0x0d 0x0a Node 0x13 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 7 0x0e 0x15 0x0f 0x0b 0x0c* 0x0d 0x0a Node 0x14 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0 Amp-Out vals: [0x00] Node 0x15 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x50a003f3: [N/A] Mic at Int N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Node 0x16 [Volume Knob Widget] wcaps 0x600000: Mono Node 0x17 [Audio Selector] wcaps 0x300903: Stereo Amp-In Amp-In caps: N/A Amp-In vals: [0x0e 0x0e] Connection: 1 0x12 Node 0x18 [Audio Selector] wcaps 0x300903: Stereo Amp-In Amp-In caps: N/A Amp-In vals: [0x80 0x80] Connection: 1 0x13 Node 0x19 [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital Node 0x1a [Audio Output] wcaps 0x30201: Stereo Digital Node 0x1b [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x405003f4: [N/A] Digital Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Connection: 1 0x1a

2 5

[alsa-devel] Sound problem in Toshiba
by Furkan Cayci 16 Jun '07

16 Jun '07

Hi, I am using Ubuntu 7.04. After installing Ubuntu, I could't hear any sound from my Toshiba Satellite A205-S4577, so I did the things related with this article; http://pastebin.ca/522731 After restarting laptop, I didn't take any errors, but there was no sound again. Then I realized the output of the dmesg. $ dmesg|grep alsa [ 18.948000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2339: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 18.948000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2343: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 18.948000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2347: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 18.948000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2355: inputs: mic=0x19, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0 [ 19.672000] ALSA /home/leonetix/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:244: si3054: cannot initialize. EXT MID = 0000 [ 19.680000] ALSA /home/leonetix/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:256: Link Frame Detect(FDT) is not ready (line status: 0000) [ 33.572000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:1810: hda_codec: model 'auto' is selected [ 33.620000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2339: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 33.620000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2343: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 33.620000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2347: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 33.620000] ALSA /home/leonetix/alsa-driver/pci/hda/hda_codec.c:2355: inputs: mic=0x19, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0 [ 34.360000] ALSA /home/leonetix/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:244: si3054: cannot initialize. EXT MID = 0000 [ 34.368000] ALSA /home/leonetix/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:256: Link Frame Detect(FDT) is not ready (line status: 0000) ------------------------- So, there is something wrong, but I didn't understand and I was wondering if you could solve or show a way to do it. Also, here is the output of lcpci -v "00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: Toshiba America Info Systems Unknown device ff10 Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at f0b40000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0" Thanks for your help, Furkan

1 0

[alsa-devel] Software mixing according to priority of streams
by Nobin Mathew 15 Jun '07

15 Jun '07

Hi, Is there any sound mixer which does mixing according to priority of streams, i.e. i will have streams with different priority like audio stream , bluettoth sco stream, gps navigation sound stream etc. Since my hardware will not support hardware mixing i will have to do this mixing in software. If bluetooth sco stream is opened while audio stream is playing then the application (sound server) should stop the playback of audio stream and should start playback of bletooth sco stream. priority order is bluettoth sco > gps navigation sound > audio Can dmix and Jack server the purpose. Nobin Mathew

3 8

[alsa-devel] [RFC][ASoC] New device/driver arch
by Liam Girdwood 15 Jun '07

15 Jun '07

I'd like to gather some feedback on some changes I've been making to ASoC recently. The changes were made to fit in better with the PPC device tree and to help with easier porting to new platforms. They were also introduced to make dealing with device probe errors (e.g. I2C probe failure) a little easier. The largest change is the introduction of an ASoC bus device. All component drivers (that is, codec, codec DAI, CPU DAI, and DMA PCM drivers) register with this bus. This should simplify device registration and hopefully better fit in with the PPC model. A component driver now typically consists of the standard driver ops and a set of ASoC/ALSA ops to configure audio. The new soc.h shows this here :- http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… Example component drivers are here :- I2S http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… DMA http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… WM8753 Codec http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… Another major change is that there is no more snd_dai_link (structure that connected codec <--> CPU). This has been replaced by an ASoC PCM device that describes each PCM device in the machine. This new ASoC PCM device has it's own driver and registers with the bus (like the others). This allows an ASoC PCM driver to be defined like :- static struct snd_soc_device_driver hifi_pcm_drv = { .type = SND_SOC_BUS_TYPE_PCM, .driver = { .name = "mainstone-hifi-pcm", .owner = THIS_MODULE, .probe = hifi_pcm_probe, .remove = hifi_pcm_remove, }, .components = { .cpu_dai = pxa2xx_i2s, .codec = wm8753_codec, .codec_dai = wm8753_hifi_dai, .platform = pxa2xx_pcm, }, }; This now shows each component within the driver structure. The snd_soc_machine driver has changed and can now contain numerous ASoC PCM devices. It is now a platform driver. Example machine driver for Mainstone with WM8753 is here :- http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… The machine driver now also does the I2C/SPI probing (instead of the codec) and also does any codec IO (to better support multiple controllers). Fwiw, I've not tested any of this code atm. I plan to start this tomorrow on pxa2xx and i.MX31 and would like to get some feedback before porting remaining platforms and codecs over. Liam

4 6