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

[alsa-devel] Is there a function I can call from my ISR to tell ALSA to abort playback?
by Timur Tabi 16 Nov '07

16 Nov '07

In my ISR, I call snd_pcm_period_elapsed() to tell it that a period has elapsed. I can also detect if playback has aborted for some reason (e.g. DMA controller has died). Is there a function I can call in my ISR to tell ALSA to abort playback or capture? -- Timur Tabi Linux kernel developer at Freescale

3 8

[alsa-devel] [PATCH] HDA-Intel - Add support for RV610/RV630 HDMI audio
by Herton Ronaldo Krzesinski 16 Nov '07

16 Nov '07

The Audio interface on HD2400/HD2600 cards isn't currently detected by snd-hda-intel. I added missing pci device ids for RV610 and RV630, but I only had a HD2400 pro card to test, where now the audio interface is detected (and no need to change patch_atihdmi.c, as the codec vendor id remains 0x1002aa01 for which we already have an entry there). I also couldn't test if sound pass-trough is ok (and I don't know how to), but at least now the device is detected. Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com.br> --- a/sound/pci/hda/hda_intel.c.orig 2007-11-02 01:59:29.000000000 -0200 +++ b/sound/pci/hda/hda_intel.c 2007-11-02 01:59:58.000000000 -0200 @@ -104,6 +104,8 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6}, "{ATI, RS690}," "{ATI, RS780}," "{ATI, R600}," + "{ATI, RV630}," + "{ATI, RV610}," "{VIA, VT8251}," "{VIA, VT8237A}," "{SiS, SIS966}," @@ -1945,6 +1947,8 @@ static struct pci_device_id azx_ids[] = { 0x1002, 0x7919, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RS690 HDMI */ { 0x1002, 0x960c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RS780 HDMI */ { 0x1002, 0xaa00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI R600 HDMI */ + { 0x1002, 0xaa08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RV630 HDMI */ + { 0x1002, 0xaa10, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RV610 HDMI */ { 0x1106, 0x3288, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_VIA }, /* VIA VT8251/VT8237A */ { 0x1039, 0x7502, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_SIS }, /* SIS966 */ { 0x10b9, 0x5461, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ULI }, /* ULI M5461 */ -- []'s Herton

3 3

[alsa-devel] alsa-lib module path question
by Ben C 16 Nov '07

16 Nov '07

Hello, I've written an ALSA external PCM plugin for a client's embedded device. During the client's compilation of alsa-lib (which I have no control over), they did not specify where the module directory should be at. In fact, they're using 1.0.13 where there isn't a configure option to specify the module directory (this was added 1.0.14?). Since this is an embedded project, due to cross compilation, alsa-lib is currently looking at some host directory that does not exist on the target to search for the libasound_module_pcm_xxx.so files. What's worse is that seems like it is dependent on where the client decides to build the RFS (say from /home/joe/project/xxx, but then later /home/bill/project/yyy) -- the alsa-lib module directory could change. For now I've manually created the non-existent host directory on the target and dropped a symbolic link there. But since that could change should they decide to rebuild the RFS, that's not even a viable bad hack solution. Is there any environment variable, configuration option or some other methods where this could be overwritten at runtime? Thank you, Ben ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

2 1

Re: [alsa-devel] [BUG] New Kernel Bugs
by Neil Brown 16 Nov '07

16 Nov '07

On Wednesday November 14, bfields(a)fieldses.org wrote: > On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote: > > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > > so please stop this "too busy and too noisy" nonsense already. It was > > > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > > > grew from a 1 million lines codebase to an 8 million lines codebase, so > > > what? Deal with it and be intelligent about filtering your information > > > influx instead of imposing a hard pre-filtering criteria that restricts > > > intelligent processing of information. > > > > So you have a preferred method of handling email. Please don't > > force it on the rest of us. > > I'd be curious for any pointers on tools, actually. I "read" (ok, skim) > lkml but still overlook relevant bug reports occasionally. > (Fortunately, between Trond and Andrew and others forwarding things it's > not actually a problem, but I'm still curious). Virtual Folders. I use VM mode in EMACS, but I believe some other mail readers have the same functionality. I have a virtual folder called "nfs" which shows me all mail in my inbox which has the string 'nfs' or 'lockd' in a To, Cc, or Subject field. When I visit that folder, I see all mail about nfs, whether it was sent to me personally, or to a relevant list, or to lkml. Admittedly if someone doesn't bother to choose a meaningful Subject, then I might miss that. I think this mostly happens when Andrew sends a "-mm" announcement, asked people to change the subject line when following up, and someone follows up without changing the subject line and say "NFS doesn't work any more". I have another virtual folder which matches "md" and "raid" and "mdadm" in any header (so when the people from coraid.com talk about ATA over Ethernet, that gets badly filed, but it is a small cost). Then I have the "bkernel" (boring kernel) folder for all mail from lkml that doesn't mention nfs or raid or md, and isn't from or to me. That folder I skim every week or so and just read the juicy debates and look for interesting tidbits from interesting people - then delete the whole folder, mostly unread. I don't think I could cope with mail without virtual folders. NeilBrown

2 1

[alsa-devel] Mitac 8252D hda_intel
by glv 15 Nov '07

15 Nov '07

(Second attempt, hope this works) Hello, I have a Mitac 8252D computer with hda_intel, it has 3 sockets in front: microphone, audio(headphones)and S/PDIF. When using 5.1 the manual says: Microphone: rear speakers Audio: front speakers S/PDIF: center and subwoofer Modprobing without any options gives me sound to the headphone and digital socket and Modprobing with model=6stack-hp gives me sound to the speakers to but they stay on when headph. are pluged in Output from alsa-info.sh: http://pastebin.ca/772406 Output from lspci -vv: 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) Subsystem: Mitac Unknown device 8253 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at fc200000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) thank you.

3 3

[alsa-devel] Removal of indirect access in control API
by Takashi Iwai 15 Nov '07

15 Nov '07

Hi, ALSA control elements have "indirect" flag, which is supposed to allow the indirect access via pointer. But, as far as I know, this feature has never been used nor implemented, and unsupported via 32/64bit compat layer. So, I'd like to get rid of this now. The clean-up patch is below. If you have objections, please let me know. thanks, Takashi --- diff -r 34e3c66d7a5c core/control.c --- a/core/control.c Mon Nov 12 18:04:54 2007 +0100 +++ b/core/control.c Mon Nov 12 18:05:16 2007 +0100 @@ -232,8 +232,6 @@ struct snd_kcontrol *snd_ctl_new1(const access = ncontrol->access == 0 ? SNDRV_CTL_ELEM_ACCESS_READWRITE : (ncontrol->access & (SNDRV_CTL_ELEM_ACCESS_READWRITE| SNDRV_CTL_ELEM_ACCESS_INACTIVE| - SNDRV_CTL_ELEM_ACCESS_DINDIRECT| - SNDRV_CTL_ELEM_ACCESS_INDIRECT| SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE| SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK)); kctl.info = ncontrol->info; @@ -692,7 +690,7 @@ int snd_ctl_elem_read(struct snd_card *c struct snd_kcontrol *kctl; struct snd_kcontrol_volatile *vd; unsigned int index_offset; - int result, indirect; + int result; down_read(&card->controls_rwsem); kctl = snd_ctl_find_id(card, &control->id); @@ -701,17 +699,12 @@ int snd_ctl_elem_read(struct snd_card *c } else { index_offset = snd_ctl_get_ioff(kctl, &control->id); vd = &kctl->vd[index_offset]; - indirect = vd->access & SNDRV_CTL_ELEM_ACCESS_INDIRECT ? 1 : 0; - if (control->indirect != indirect) { - result = -EACCES; - } else { - if ((vd->access & SNDRV_CTL_ELEM_ACCESS_READ) && kctl->get != NULL) { - snd_ctl_build_ioff(&control->id, kctl, index_offset); - result = kctl->get(kctl, control); - } else { - result = -EPERM; - } - } + if ((vd->access & SNDRV_CTL_ELEM_ACCESS_READ) && + kctl->get != NULL) { + snd_ctl_build_ioff(&control->id, kctl, index_offset); + result = kctl->get(kctl, control); + } else + result = -EPERM; } up_read(&card->controls_rwsem); return result; @@ -748,7 +741,7 @@ int snd_ctl_elem_write(struct snd_card * struct snd_kcontrol *kctl; struct snd_kcontrol_volatile *vd; unsigned int index_offset; - int result, indirect; + int result; down_read(&card->controls_rwsem); kctl = snd_ctl_find_id(card, &control->id); @@ -757,23 +750,19 @@ int snd_ctl_elem_write(struct snd_card * } else { index_offset = snd_ctl_get_ioff(kctl, &control->id); vd = &kctl->vd[index_offset]; - indirect = vd->access & SNDRV_CTL_ELEM_ACCESS_INDIRECT ? 1 : 0; - if (control->indirect != indirect) { - result = -EACCES; + if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) || + kctl->put == NULL || + (file && vd->owner && vd->owner != file)) { + result = -EPERM; } else { - if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) || - kctl->put == NULL || - (file && vd->owner != NULL && vd->owner != file)) { - result = -EPERM; - } else { - snd_ctl_build_ioff(&control->id, kctl, index_offset); - result = kctl->put(kctl, control); - } - if (result > 0) { - up_read(&card->controls_rwsem); - snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, &control->id); - return 0; - } + snd_ctl_build_ioff(&control->id, kctl, index_offset); + result = kctl->put(kctl, control); + } + if (result > 0) { + up_read(&card->controls_rwsem); + snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, + &control->id); + return 0; } } up_read(&card->controls_rwsem); diff -r 34e3c66d7a5c include/asound.h --- a/include/asound.h Mon Nov 12 18:04:54 2007 +0100 +++ b/include/asound.h Mon Nov 12 18:05:16 2007 +0100 @@ -738,8 +738,7 @@ typedef int __bitwise snd_ctl_elem_iface #define SNDRV_CTL_ELEM_ACCESS_OWNER (1<<10) /* write lock owner */ #define SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK (1<<28) /* kernel use a TLV callback */ #define SNDRV_CTL_ELEM_ACCESS_USER (1<<29) /* user space element */ -#define SNDRV_CTL_ELEM_ACCESS_DINDIRECT (1<<30) /* indirect access for matrix dimensions in the info structure */ -#define SNDRV_CTL_ELEM_ACCESS_INDIRECT (1<<31) /* indirect access for element value in the value structure */ +/* bits 30 and 31 are obsoleted (for indirect access) */ /* for further details see the ACPI and PCI power management specification */ #define SNDRV_CTL_POWER_D0 0x0000 /* full On */ @@ -793,30 +792,25 @@ struct snd_ctl_elem_info { } value; union { unsigned short d[4]; /* dimensions */ - unsigned short *d_ptr; /* indirect */ } dimen; unsigned char reserved[64-4*sizeof(unsigned short)]; }; struct snd_ctl_elem_value { struct snd_ctl_elem_id id; /* W: element ID */ - unsigned int indirect: 1; /* W: use indirect pointer (xxx_ptr member) */ + unsigned int indirect: 1; /* W: indirect access - obsoleted */ union { union { long value[128]; - long *value_ptr; } integer; union { long long value[64]; - long long *value_ptr; } integer64; union { unsigned int item[128]; - unsigned int *item_ptr; } enumerated; union { unsigned char data[512]; - unsigned char *data_ptr; } bytes; struct snd_aes_iec958 iec958; } value; /* RO */

2 2

[alsa-devel] interrupting snd_pcm_writei or snd_pcm_drain?
by Mike Gorse 15 Nov '07

15 Nov '07

I've noticed that it is unsafe to call snd_pcm_writei or snd_pcm_drain in a pthread with its cancelation type set to asynchronous. snd_pcm_dmix_sync_area can lower a semaphore, and, if the thread is canceled while the semaphore is down, then a subsequent call to the sound device (calling snd_pcm_close, for instance) will also lower the semaphore and cause deadlock. Is this a known issue, and is there a way around it other than to always use deferred cancelation when calling these functions? Thanks, -Mike G-

2 1

Re: [alsa-devel] [BUG] New Kernel Bugs
by Neil Brown 15 Nov '07

15 Nov '07

On Tuesday November 13, vda.linux(a)googlemail.com wrote: > On Tuesday 13 November 2007 07:08, Mark Lord wrote: > > Ingo Molnar wrote: > > .. > > > > > This is all QA-101 that _cannot be argued against on a rational basis_, > > > it's just that these sorts of things have been largely ignored for > > > years, in favor of the all-too-easy "open source means many eyeballs and > > > that is our QA" answer, which is a _good_ answer but by far not the most > > > intelligent answer! Today "many eyeballs" is simply not good enough and > > > nature (and other OS projects) will route us around if we dont change. > > > > .. > > > > QA-101 and "many eyeballs" are not at all in opposition. > > The latter is how we find out about bugs on uncommon hardware, > > and the former is what we need to track them and overall quality. > > > > A HUGE problem I have with current "efforts", is that once someone > > reports a bug, the onus seems to be 99% on the *reporter* to find > > the exact line of code or commit. Ghad what a repressive method. > > This is the only method that scales. That sounds overly hash, and the rest of you mail sounds much more moderate and sensible - I can only assume you were using hyperbole?? Putting the "onus on the reporter" is simply not going to work unless you have a business relationship. In the community, we are all volunteering our time (well, maybe my employer is volunteering my time to do community support, but the effect is the same). I would hope that the focus of developers is to empower bug reporters to provide further information (and as has been said, "git bisect" is a great empowerer). Some people will be incredibly help, especially if you ask politely and say thankyou. Others won't for any of a number of reasons - and maybe that means their bug won't get fixed. To my eyes, the "only method that scales" is investing effort in encouraging and training bug reporters. Some of that effort might not produce results, but when others among those you have encouraged start answering the newbee questions on the list and save you the time, you get a distinct feeling that it was all worth while. I think we are in agreement - I just wanted to take issue with that one sentence :-) The rest is great. NeilBrown > > Developer has only 24 hours in each day, and sometimes he needs to eat, > sleep, and maybe even pay attention to e.g. his kids. > > But bug reporters are much more numerous and they have more > hours in one day combined. > > BUT - it means that developers should try to increase user base, > not scare users away. > > > And if the "developer" who broke the damn thing, or who at least > > "claims" to be supporting that code, cannot "reproduce" the bug, > > they drop it completely. > > Developer should let reporter know that reporter needs to help > a bit here. Sometimes a bit of hand holding is needed, but it > pays off because you breed more qualified testers/bug reporters. > > > Contrast that flawed approach with how Linus does things.. > > he thinks through the symptoms, matches them to the code, > > and figures out what the few possibilities might be, > > and feeds back some trial balloon patches for the bug reporter to try. > > > > MUCH better. > > > > And remember, *I'm* an old-time Linux kernel developer.. just think about > > the people reporting bugs who haven't been around here since 1992.. > > Yes. Developers should not grow more and more unhelpful > and arrogant towards their users just because inexperienced > users send incomplete/poorly written bug reports. > They need to provide help, not humiliate/ignore. > > I think we agree here. > -- > vda > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/

1 0

[alsa-devel] params_buffer_size() and params_period_bytes() are returning the same value
by Timur Tabi 14 Nov '07

14 Nov '07

I have an ASOC v1 driver that I'm wrapping up. I've noticed something weird in my hw_params() function. I have this code: size_t buffer_size = params_buffer_size(hw_params); size_t period_size = params_period_bytes(hw_params); printk(KERN_INFO "%s: buffer_size=%x period_size=%x\n", __FUNCTION__, buffer_size, period_size); printk(KERN_INFO "%s: params_periods=%u\n", __FUNCTION__, params_periods(hw_params)); And it produces this output: fsl_dma_hw_params: buffer_size=5dc0 period_size=5dc0 fsl_dma_hw_params: params_periods=4 Why am I getting the same value for buffer_size and period_size? buffer_size should be four times period_size. -- Timur Tabi Linux kernel developer at Freescale

1 1

Re: [alsa-devel] [PATCH] ASoC TLV320AIC3X codec driver
by Vladimir A. Barinov 14 Nov '07

14 Nov '07

Hello Takashi, Thank you for the review. Takashi Iwai wrote: > At Tue, 13 Nov 2007 22:41:25 +0300, > Vladimir Barinov wrote: > >> --- /dev/null >> +++ linux-2.6.24.rc2.alsa/sound/soc/codecs/tlv320aic3x.c >> > (snip) > >> + >> +struct snd_soc_codec_device soc_codec_dev_aic3x; >> > > Do you need this here? It's defined in the later position. > You are right. Thanks for pointing to this. That is an artefact of the driver that I based on. > >> +/* >> + * All input lines are connected when !0xf and disconnected with 0xf bit field, >> > > Please keep the line within 80 chars. Try to run checkpatch.pl in > linuxkernel/scripts for checking such minor coding-style issues. > But this line is less then 80 chars :) I've applied checkpatch.pl before sending the patch. The driver really has 3 lines with 80 chars warning, but they are less then 82 char. It's in the codec interconnection map for DAPM. If that is a strong demand with 80 chars _warning_ then I'll try to rename the mixers/path/endpoint names to match, if not then the code will be more understandable. That lines are: + {"Right HPCOM Mux", "differential of HPROUT", "Right Line2 Bypass Mixer"}, + {"Right HPCOM Mux", "differential of HPLCOM", "Right Line2 Bypass Mixer"}, If I'll split it with 2 lines each then will it be good to watch in accordance with DAPM usage strategy? Destination Widget <=== Path Name <=== Source Widget > >> +static const char *aic3x_left_dac_mux[] = { "DAC_L1", "DAC_L3", "DAC_L2" }; >> +static const char *aic3x_right_dac_mux[] = { "DAC_R1", "DAC_R3", "DAC_R2" }; >> +static const char *aic3x_left_hpcom_mux[] = >> + { "differential of HPLOUT", "constant VCM", "single-ended" }; >> +static const char *aic3x_right_hpcom_mux[] = >> + { "differential of HPROUT", "constant VCM", "single-ended", >> + "differential of HPLCOM", "external feedback" }; >> +static const char *aic3x_linein_mode_mux[] = { "single-ended", "differential" }; >> > > Ditto. > Ditto :) These lines are less then 80 chars. > >> +#define AIC3X_RATES SNDRV_PCM_RATE_8000_96000 >> +#define AIC3X_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE | \ >> + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE) >> > > Are you sure that it's FMTBIT_S24_LE? It's not packed in 3 bytes but > uses lower 3 bytes of 4 bytes frame. > > Aic3x supports 16/20/24/32 bits data word length and in accordance with aic33 documentation the number of clocks per half-frame for each channel are equal to exact number of bits of the word. Unfortunately, now I have no h/w to test 24bits mode. > >> Index: linux-2.6.24.rc2.alsa/sound/soc/codecs/Kconfig >> =================================================================== >> --- linux-2.6.24.rc2.alsa.orig/sound/soc/codecs/Kconfig >> +++ linux-2.6.24.rc2.alsa/sound/soc/codecs/Kconfig >> @@ -37,3 +37,6 @@ config SND_SOC_CS4270_VD33_ERRATA >> bool >> depends on SND_SOC_CS4270 >> >> +config SND_SOC_TLV320AIC3X >> + tristate >> + depends on SND_SOC >> > > Currently, there is a known problem with dependency on I2C over soc > codecs drivers. If CONFIG_I2C=m and CONFIG_SND_SOC_*=y, you'll get > unresolved symbols. > > I don't know how to resolve this issue right now. But, the drivers > that support *only* I2C right now can add "depends on I2C" to its > Kconfig. That doesn't work for CS4270 which may work without I2C as > standalone mode, though. > Ok, will add I2C dependency. Regards, Vladimir

3 4