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

[alsa-devel] E-mu 1212M/1820M/1616M development
by Ctirad Fertr 18 Nov '07

18 Nov '07

Hello, I just bought an 1616M PCMCIA in addition to my old 1212m v1 and want to help improve the current driver. I wrote one little patch for those cards in the past (and some bigger patches for my experiments which were never released) and now I have some time to continue. I'm going to add missing switches into mixer, make some changes in mixer to match the real I/O setup of each particular card model and perhaps also write some graphics patchmix like app. Unfortunatelly, I'm unable to fix the most important bugs (at least from my point of view) dua to lack of documentation and knowlenge of DSP programming. These are: 1. non working 24bit playback. It should be on device 0,2 This device exists, but cannot be openned for playback.It is the last thing needed for serious DAW. 2. Non working S/PDIF (and probably ADAT, too) on 1616(M) microdock ports. I think tese ports uses different set of registers than PCI 1010 host card. Am I right? 3. Midi I/O works well on 1212m v1, but only when 48kHz is set. At 44.1kHz signalling is corrupted (different UART timing? How to fix it?). On 1616m microdock MIDI I/O does not work at all. I welcome any comments, advices and patches ;) ---- Ctirad

3 5

[alsa-devel] [CONF] All C-Media Codecs based 5.1 Channel USB- Headsets
by thomas schorpp 18 Nov '07

18 Nov '07

Report to devlist as requested from USB-Audio.conf header: 1. all this headsets with windriver inf files + manual showing c-media driver must have the cm106x series 7.1 channel usb-codec in. there's no other from c-media for the design of 5.1 channel usb headsets available at this time, see: http://www.cmedia.com.tw/?q=en/usb_audio 2. the headset interface shows up with 8 channels in lsusb -v , 1 8-ch pcm in /proc, and must be driven with surround7.1 pcm plug instead of surround5.1 or it will not work. speaker-test program works with -c6 -Dsurround7.1, test with -c8 works too, but shows that no SideL/R -speakers connected/routed/downmixed ( Speedlink Medusa 5.1 Mobile USB Headset, cm106L) 3. it works instantly without extra config using programs that allow specifying (-D)surround7.1 like VDR and MPlayer, VLC did not so far (maybe can do with special commandline) and therere maybe other unconfigurable (or buggy?) players that need a missing extra cm106 CARD configfile showing those apps a 5.1 channel device instead a 7.1. i've done none so far, the config file language (especially routing and mappings) is not well documented, sorry. y tom

2 4

[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