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

[alsa-devel] [ASoc] TDM over one SSC channel on AT91 possible?
by Friedrich Lobenstock 24 Jun '11

24 Jun '11

Hello! The background: I'm just designing an ATMEL AT91RM9200 based board which got two TLV320AIC33 on board. It is either possible to hook up the two TLV320AIC33 to a separate SSC (synchronous serial control) channel each or use one SSC channel and configure it for TDM (time division multiplex) mode. There is already a driver for TLV320AIC14k/TLV320AIC2k in the development tree, so adding support for the TLV320AIC33 should be feasible. What I'm not sure about is the fact if ASOC is prepared for using channels, especially SSC, in TDM mode. Is the core ASOC structure prepared to handle that? Would we be better off instantiate one drive twice each time with different parameters for the SSC channel? Thanks for any feedback. -- MfG / Regards Friedrich Lobenstock _________________________________________________________ SCOTTY Group Austria GmbH a SCOTTY Group plc company, http://www.scottygroup.com/ _________________________________________________________

4 3

[alsa-devel] idt STAC927x adat supported (sigmatel HDA codec) ?
by Eric 03 Mar '11

03 Mar '11

Is the ADAT output of the IDT (sigmatel) STAC927x HDA codec supported in alsa ? If not could someone please try to add this incredibly nice feature in the existing alsa driver ? Thank you very much

4 13

Re: [alsa-devel] Patchmix-style application for EMU cards
by Camilo Polymeris 30 Aug '10

30 Aug '10

Hello > That is more or less what I had figured out, but it how are playback_1 to > > _16 channels routed to DSP0-15? It seems that it depends on the setting > of > > Front, Surround, LFE, etc. mixer controls. If they are turned up, I > don't > > understand what happens, sound to playback channels appears on various > DSP > > buses, at different levels. > > Really? Well, I didn't much experiment with surround mode. In source code, > I > can see that there are up to playback 8 channels at hw:0,0 with can be > controlled by faders in alsamixer. I tried surround40 and surroun51 on my > emu1616m and it worked as expected. The channles were mapped to first > couple > of DSP ports in a correct order. In fact this should work the same as > audigy > does, except the result is passed to DSP ports instead of physical > outputs. > On my card, playback channels 1 & 2 (hw:0,3) appear on all DSP busses associated with surround. Say you turn up the "Side" fader in alsamixer, channels 1 & 2 will appear at the relevant DSPs (6-7, I think) Whatever, for now I am just keeping all surround controls down (that is, Front, Surround, Center, Side & LFE). > Anyway, I think if there is another layer of routing done in audigy DSP, > it > shouldn't be used in EMU specific application. Or at least not for now. > The > most important thing is to provide all the switches and FPGA routing > scheme > for each EMU model. Or, to be precise, three routing schemes for each EMU > model, because for "double speed" (e.g. 96kHz) and "quadro speed" (e.g. > 192kHz) modes of operation the numebr of both physical and virtual > channels > changes. > I think the switches and enums for the card models are rather trivial, one can handle it with a customized version of qamix (done with a simple XML file), for example. A separate application would not be necessary for only that. > > If I turn the Front/Surround/LFE/etc. faders down, I can mix playback > > channels to DSP using the "Multichannel PCM Send/Routing/Volume" faders, > in > > a more or less intuitive way, besides that routing values do not map > > directly to DSP buses (i.e. 14-15 map to DSP0-1, but 2-3 map to DSP2-3). > Handling of this controls motivated me to write the application in the first place. No sound at all will appear if I don't set the appropiate controls for each playback channel: Multichannel PCM Volume (full), Multichannel PCM Send (an index of 8 controls, the first 4 select the target DSP) & Multichannel PCM Send Volume (again faders 0-3 of 8) By the way, only DSP0-7 work in this way. I have no idea how to make DSP8-31 work. On which card you did tested it? The driver was primary written for the > 1820M/1212M V1, so some things may not work well on other models and need > to > be fixed. I have a 1212m, don't know which version, but I think it's V1-- it does have firewire. I am using driver version 1.0.16. Thanks, Camilo.

3 3

[alsa-devel] Audio buffer mmap-ing on sh arch vs. cache aliasing problem
by Pawel MOLL 16 Jan '10

16 Jan '10

Hi Guys, Recently I was investigating an issue with capturing audio using USB Audio Class device on a sh4-based board. "Bad voice quality" was reported... Finally I have traced the problem to something which is (unfortunately) well known to sh developers as a D-cache aliasing (or synonym) problem. Briefly speaking: due to some MMU design decisions, one can have two different virtual address pointing to the same physical location, which is fine, but going via different cache slots! So if there was a value of "0" in the memory and user "A" will write "1" there, user "B" will still read "0"... The solution is to ensure all TLB entries (so virtual memory areas) are beginning from a 16kB-aligned virtual address. Otherwise it is necessary to flush the cache between accesses from "A" and "B" sides. And now. The USB Audio Class driver (sound/usb/usbaudio.c) is allocating the sound buffer like this... static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) { [...] runtime->dma_area = vmalloc(size); [...] } ... and vmalloc will return a page(4k)-aligned pointer, possibly not 16k-aligned one. This is the source of all evil ;-) When using RW transfers everything is fine, as data is memcopied between two independent buffers. In a case of MMAP mode we will end up with such a situation: 1. The driver will memcpy data from an URB to the buffer. It will populate several cache lines. Let's call it a "kernel cache". 2. As the library has mapped the non-16k-aligned address via different cache line ("user cache"), it will read some rubbish from the physical memory, populating the "user cache" by the way. 3. Some time later the "kernel cache" is flushed, writing the data to the memory. 4. Some new data from URB is entering "kernel cache". 5. The library will access mmap-ed area again, going via the "user cache", which may or may not reflect the correct data (depending on the fact was the "user cache" flushed or not) etc. Of course this cycle is completely not deterministic, so some of the "kernel cache" lines will be flushed before being accessed from user space, other not... The final effect is... hmm... bizarre :-) First, of course, you will get a (probably loud) glitch (rubbish from buffer's underlying memory, before the first valid data is written back), and then something that could be described as an "echo" ;-) I mean - you are capturing "1 2 3 4 5 6 7..." and the result is (G stands for Glitch ;-) "G 1 23 3 4 4 6 67..." As a quick-and-dirty work-around I have modified snd_pcm_alloc_vmalloc_buffer() to allocate always 12kB more and then use 16k-aligned pointer: static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) { struct snd_pcm_runtime *runtime = subs->runtime; if (runtime->dma_addr) { if (runtime->dma_bytes >= size) return 0; /* already large enough */ vfree((void *)runtime->dma_addr); } runtime->dma_addr = (unsigned long)vmalloc(size + 12 * 1024); if (!runtime->dma_addr) return -ENOMEM; runtime->dma_area = (void *)ALIGN(runtime->dma_addr, 16 * 1024); runtime->dma_bytes = size; return 0; } Of course it cannot be regarded as anything more as a hack. And definitely not as a solution... So my question is: Any idea how the "proper solution" should look like? I see no obvious method to get an arch-independent "mmap-compliant" buffer. This problem was found on a sh arch, using an USB Audio Class device, however out there some other architectures are suffering from this MMU "feature" as well (ie. see http://docs.hp.com/en/B3906-90006/ch07s09.html) and possibly other drivers could behave "wrongly" (quoted as the driver is actually innocent...) To be honest I just have absolutely no idea what to do with this all! :-O I hope I was clear enough in the description... Any feedback, advise, idea etc. will be more than appreciated. Cheers Paweł

3 11

[alsa-devel] Intel G45 8-Channel LPCM over HDMI
by Alexander Werner 11 Dec '09

11 Dec '09

Hi, I'm planning to build a linux-based, small sized PC for hearing aid acousticians. It would be highly unfavorable, if the connection between Receiver and PC was analog, because of the lower quality and the high number of cables. I searched for a appropriate mainboard, and found the DG45FC, which fits my needs perfectly, apart from the missing audio over HDMI support. Is there any plan to support multichannel LPCM output over HDMI on the Intel G45 platform? If not, is there anyone willing to implement HDMI support for the G45 chipset if I donate the needed hardware (permanently)? But if there's no chance to implement it in the near future, has anyone experience with an onboard chipset with multichannel LPCM over HDMI and ALSA support? Thanks, Alexander Werner

7 10

[alsa-devel] Trying to get unsupported CODEC to work
by Alex Austin 05 Nov '09

05 Nov '09

HelloI have an MSI Media Live DIVA motherboard. It has an AMD SB600 HD Audio controller, and two CODECs on the HDA bus. First is an ALC888 Second is an Intersil DAE-3. Two alsa-info outputs in different circumstances http://www.alsa-project.org/db/?f=20c86e755fdbbdbc8761c8c2f4de76bce2ea0c11 http://www.alsa-project.org/db/?f=15c5e5eab0104622a84b2dd0df03f26c17c7242d Output of codecgraph with "modprobe hda-intel probe_mask=2" http://pastebin.com/f54b6a9b8 What's the next step to get this supported? -- - Alex Austin (651) 238-9273 "...and then I visited Wikipedia ...and the next 8 hours are a blur."

3 13

Re: [alsa-devel] Acer Aspire 7730G support
by Denis Kup 24 Aug '09

24 Aug '09

2009/6/24 Denis Kup <dener.kup(a)gmail.com>: > 2009/6/24 Takashi Iwai <tiwai(a)suse.de>: >> At Wed, 24 Jun 2009 16:09:58 +0400, >> Denis Kup wrote: >>> >>> Hey, when i first installed alsa to my laptop, there no sound from >>> subwoofer, jacks were map very strange (2 surrounds for ex.). I try >>> all models from the list, but all don't support my subwoofer. After a >>> weak of hard work i made a patch that enables ACER_ASPIRE_7730G model >>> for my laptop. It have ALC888S, 3 jacks, 6 channels, stereo internal >>> frontal speakers and internal subwoofer.You can see acer.com for more >>> info about hardware and jacks. >>> >>> It's the changes i made to /alsa-kernel/pci/hda/patch_realtek.c: >> >> Can you try Emilio's patch recently posted (and pass >> model=acer-aspire-6530g) with the very latest alsa-driver-snapshot? >> This essentially includes your changes. It's in: >> From: Emilio López <buhitoescolar(a)gmail.com> >> Subject: Re: [alsa-devel] Regarding Sound on Acer Aspire 6935G >> Date: Tue, 23 Jun 2009 22:32:45 -0300 >> Message-ID: <d54969c50906231832w48ce7315uc5cf8b3f81534c76(a)mail.gmail.com> >> >>> After changing file i install driver, and it automatically detect its >>> model (maybe there are old settings from previous install, so i dont >>> 100% sure that it was detected). With this settings subwoofer works >>> perfect, internal stereo and subwoofer mute when headphone are plugged >>> all works, except 1 thing: subwoofer uses center channel instead LFE. >>> To fix it i use such asound.conf file: >> ... >>> Is there any chance to swap Center and LFE in patch_realtek.c? >> >> Unlikely as ALC888* doesn't support the channel-swap feature (although >> some other ALC codecs do). >> >> >> thanks, >> >> Takashi >> > > You are talking about that > http://mailman.alsa-project.org/pipermail/alsa-devel/2009-June/018815.html > ?? Its right link to drivers http://www.alsa-project.org/snapshot/ ?? > And there is easier way to apply patches than manually adding strings > to files? > I manage with installing. I use alsa-driver-snapshot.tar.gz http://ftp.kernel.org/pub/linux/kernel/people/tiwai/alsa/alsa-driver/ and this Amilo changes http://mailman.alsa-project.org/pipermail/alsa-devel/2009-June/018815.html . But this patch has smaller functionality against i have. There is advantages and disadvantages of both patches: My patch: + 1) when black jack plugged, internal speakers and subwoofer mute + 2) there is 3 maps for jacks: (black/pink/blue) 2ch: front/ext mic/ (something i dont know, it should be line in), 4ch: front/ ext mic/ side 6ch: front/ CLFE / side; (its changes in channel mode option in mixer) + 3) internal mic works + 4) there are separate boost mic channels for internal and external mics - 5) internal subwoofer controls with Center channel in mixer ? 6) i dont know how line in works (i will check it when reinstall to my patch) ? 7) i dont know how spdif works, because i have not any spdif speakers in house Amilo patch: - 1) when black jack pluged, only internal speaker mutes, subwoofer continue to work (it has no meaning when i listen to music in headphones) - 2) there is only 1 map for jacks: front/ext mic/ (something i dont know, it should be line in) - 3) there no side and center channels - 3) internal mic dont work - 4) there no line in in input source menu in mixer + 5) Subwoofer controls with LFE channel in mixer ? 7) i dont know how spdif works, because i have not any spdif speakers in house

3 4

[alsa-devel] load_for_all_cards bug
by Kevin Goodsell 10 Aug '09

10 Aug '09

(I originally tried to send this via the moderator without subscribing to the list, but it never went through and I never received a moderator response. Apparently this list is set up as moderated, but nobody is actually moderating it.) Summary: load_for_all_cards fails with existing configuration elements In snd_config_hook_load_for_all_cards, the first call to snd_config_search attempts to locate an existing configuration node with the name of the driver. Typically none is found, and everything is good. However, if such a node is located, the next line assumes it is a leaf node with type 'string' and calls snd_config_get_string to fetch the string value. If this fails, the entire hook is abandoned. Because of this, setting something like the following in asoundrc: cards.<driver name>.foo 0 is sufficient to disable the entire card-specific configuration. As a concrete example, I have a HDA-Intel sound card. dmix.conf includes a way to set period_size, period_time, and periods by using configuration elements of the form cards.<driver name>.pcm.dmix.<var>. In ~/.asoundrc I add cards.HDA-Intel.pcm.dmix.period_size 1024 This will cause HDA-Intel.conf to fail to load, and the pcm defined in default.conf will fail to find the device-specific pcm cards.HDA-Intel.pcm.default, and fall back on the default pcm using plughw. By attempting to configure dmix, I have disabled it. Fixing this may just be a matter of changing the line in snd_config_hook_load_for_all_cards from: if (snd_config_search(root, fdriver, &n) >= 0) { to: if (snd_config_search(root, fdriver, &n) >= 0 && n->type != SND_CONFIG_TYPE_COMPOUND) { I have not tested this. -Kevin

2 1

[alsa-devel] [PATCH 1/3] ASoC: change set_tdm_slot api to allow slot_width override.
by Daniel Ribeiro 06 Aug '09

06 Aug '09

Extend set_tdm_slot to allow the user to arbitrarily set the frame width and active TX/RX slots. Updates magician.c and wm9081.c for the new set_tdm_slot(). wm9081.c still doesn't handle the slot_width override. While being there, correct an incorrect use of SlotsPerFrm(7) use in bitmask on pxa-ssp.c (SSCR0_SlotsPerFrm(x) is (((x) - 1) << 24)) ). (this series is meant for Mark's for-2.6.32 branch) Signed-off-by: Daniel Ribeiro <drwyrm(a)gmail.com> --- include/sound/soc-dai.h | 5 +++-- sound/soc/codecs/wm9081.c | 5 +++-- sound/soc/pxa/magician.c | 2 +- sound/soc/pxa/pxa-ssp.c | 27 ++++++++++++++++++++------- sound/soc/soc-core.c | 9 ++++++--- 5 files changed, 33 insertions(+), 15 deletions(-) diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h index 352d7ee..6692410 100644 --- a/include/sound/soc-dai.h +++ b/include/sound/soc-dai.h @@ -106,7 +106,7 @@ int snd_soc_dai_set_pll(struct snd_soc_dai *dai, int snd_soc_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt); int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai, - unsigned int mask, int slots); + unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width); int snd_soc_dai_set_tristate(struct snd_soc_dai *dai, int tristate); @@ -140,7 +140,8 @@ struct snd_soc_dai_ops { */ int (*set_fmt)(struct snd_soc_dai *dai, unsigned int fmt); int (*set_tdm_slot)(struct snd_soc_dai *dai, - unsigned int mask, int slots); + unsigned int tx_mask, unsigned int rx_mask, + int slots, int slot_width); int (*set_tristate)(struct snd_soc_dai *dai, int tristate); /* diff --git a/sound/soc/codecs/wm9081.c b/sound/soc/codecs/wm9081.c index 86fc57e..c47d573 100644 --- a/sound/soc/codecs/wm9081.c +++ b/sound/soc/codecs/wm9081.c @@ -1206,8 +1206,9 @@ static int wm9081_set_sysclk(struct snd_soc_dai *codec_dai, return 0; } +/* FIXME: Needs to handle slot_width */ static int wm9081_set_tdm_slot(struct snd_soc_dai *dai, - unsigned int mask, int slots) + unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width) { struct snd_soc_codec *codec = dai->codec; unsigned int aif1 = wm9081_read(codec, WM9081_AUDIO_INTERFACE_1); @@ -1219,7 +1220,7 @@ static int wm9081_set_tdm_slot(struct snd_soc_dai *dai, aif1 |= (slots - 1) << WM9081_AIFDAC_TDM_MODE_SHIFT; - switch (mask) { + switch (rx_mask) { case 1: break; case 2: diff --git a/sound/soc/pxa/magician.c b/sound/soc/pxa/magician.c index c89a3cd..34437d8 100644 --- a/sound/soc/pxa/magician.c +++ b/sound/soc/pxa/magician.c @@ -188,7 +188,7 @@ static int magician_playback_hw_params(struct snd_pcm_substream *substream, if (ret < 0) return ret; - ret = snd_soc_dai_set_tdm_slot(cpu_dai, 1, 1); + ret = snd_soc_dai_set_tdm_slot(cpu_dai, 1, 0, 1, width); if (ret < 0) return ret; diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c index e22c5ce..5b9ed64 100644 --- a/sound/soc/pxa/pxa-ssp.c +++ b/sound/soc/pxa/pxa-ssp.c @@ -375,21 +375,34 @@ static int pxa_ssp_set_dai_pll(struct snd_soc_dai *cpu_dai, * Set the active slots in TDM/Network mode */ static int pxa_ssp_set_dai_tdm_slot(struct snd_soc_dai *cpu_dai, - unsigned int mask, int slots) + unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width) { struct ssp_priv *priv = cpu_dai->private_data; struct ssp_device *ssp = priv->dev.ssp; u32 sscr0; - sscr0 = ssp_read_reg(ssp, SSCR0) & ~SSCR0_SlotsPerFrm(7); + sscr0 = ssp_read_reg(ssp, SSCR0); + sscr0 &= ~(SSCR0_MOD | SSCR0_SlotsPerFrm(8) | SSCR0_EDSS | SSCR0_DSS); + + /* set slot width */ + if (slot_width > 16) + sscr0 |= SSCR0_EDSS | SSCR0_DataSize(slot_width - 16); + else + sscr0 |= SSCR0_DataSize(slot_width); - /* set number of active slots */ - sscr0 |= SSCR0_SlotsPerFrm(slots); + if (slots > 1) { + /* enable network mode */ + sscr0 |= SSCR0_MOD; + + /* set number of active slots */ + sscr0 |= SSCR0_SlotsPerFrm(slots); + + /* set active slot mask */ + ssp_write_reg(ssp, SSTSA, tx_mask); + ssp_write_reg(ssp, SSRSA, rx_mask); + } ssp_write_reg(ssp, SSCR0, sscr0); - /* set active slot mask */ - ssp_write_reg(ssp, SSTSA, mask); - ssp_write_reg(ssp, SSRSA, mask); return 0; } diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index e1a920c..c72a8e8 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2133,17 +2133,20 @@ EXPORT_SYMBOL_GPL(snd_soc_dai_set_fmt); /** * snd_soc_dai_set_tdm_slot - configure DAI TDM. * @dai: DAI - * @mask: DAI specific mask representing used slots. + * @tx_mask: bitmask representing active TX slots. + * @rx_mask: bitmask representing active RX slots. * @slots: Number of slots in use. + * @slot_width: Width in bits for each slot. * * Configures a DAI for TDM operation. Both mask and slots are codec and DAI * specific. */ int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai, - unsigned int mask, int slots) + unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width) { if (dai->ops && dai->ops->set_tdm_slot) - return dai->ops->set_tdm_slot(dai, mask, slots); + return dai->ops->set_tdm_slot(dai, tx_mask, rx_mask, + slots, slot_width); else return -EINVAL; } -- tg: (c787980..) asoc/set_tdm_slot (depends on: asoc/remove-code-duplication) -- Daniel Ribeiro

6 6

[alsa-devel] my udev rules are breaking my dmixer setup why?
by Jelle de Jong 29 Jul '09

29 Jul '09

Hello everybody, I am trying to use udev to get fixed device names depending on the location of the device on the usb bus. The udev rules seems to be working fine, however i cant get dmix to work with the udev rules using only hw dies work. If i remove the udev rules the dmixer works fine. Can somebody look at the attachment, and maybe do some testing, i would highly appreciate it. I am also on chat.freenode.org and #alsa as tuxcrafter Thanks in advance, Jelle ls -hal /dev/snd/ total 0 drwxr-xr-x 2 root root 320 2008-11-09 15:44 . drwxr-xr-x 12 root root 4.8K 2008-11-09 15:50 .. crw-rw---- 1 root user0 116, 0 2008-11-09 15:44 controlC0 crw-rw---- 1 root user1 116, 32 2008-11-09 15:44 controlC1 crw-rw---- 1 root user2 116, 64 2008-11-09 15:44 controlC2 crw-rw---- 1 root user3 116, 96 2008-11-09 15:44 controlC3 crw-rw---- 1 root user0 116, 24 2008-11-09 15:44 pcmC0D0c crw-rw---- 1 root user0 116, 16 2008-11-09 15:49 pcmC0D0p crw-rw---- 1 root user1 116, 56 2008-11-09 15:44 pcmC1D0c crw-rw---- 1 root user1 116, 48 2008-11-09 15:44 pcmC1D0p crw-rw---- 1 root user2 116, 88 2008-11-09 15:44 pcmC2D0c crw-rw---- 1 root user2 116, 80 2008-11-09 15:44 pcmC2D0p crw-rw---- 1 root user3 116, 120 2008-11-09 15:44 pcmC3D0c crw-rw---- 1 root user3 116, 112 2008-11-09 15:44 pcmC3D0p crw-rw---- 1 root audio 116, 1 2008-11-09 15:44 seq crw-rw---- 1 root audio 116, 33 2008-11-09 15:44 timer ------------------------------------------------------------------------ udevinfo info --attribute-walk --name=/dev/snd/controlC0 ------------------------------------------------------------------------ echo 'SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="controlC[0-9]*", NAME="snd/controlC4" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="controlC[0-9]", NAME="snd/controlC5" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="controlC[0-9]", NAME="snd/controlC6" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="controlC[0-9]", NAME="snd/controlC7" SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC4D0c" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC5D0c" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC6D0c" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC7D0c" SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC4D0c" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC5D0c" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC6D0c" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC7D0c" SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC4D0p" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC5D0p" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC6D0p" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC7D0p"' | tee /etc/udev/rules.d/10-persistent-sound.rules chmod 600 /etc/udev/rules.d/10-persistent-sound.rules ------------------------------------------------------------------------ # without dmixer # this works .... echo 'pcm.softvol { type softvol slave.pcm hw:1 control.name Master control.card 1 } pcm.!default { type plug slave.pcm softvol } ctl.!default { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc ------------------------------------------------------------------------ # with dmixer # this does not work echo 'pcm.softvol { type softvol slave.pcm dmix:1 control.name Master control.card 1 } pcm.!default { type plug slave.pcm softvol } ctl.!default { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc ------------------------------------------------------------------------ # with dmixer # this does not work echo 'pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 2048 slave.pcm hw:1 } ctl.dmixer { type hw card 1 } pcm.dsp { type plug slave.pcm dmixer } ctl.mixer { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc ------------------------------------------------------------------------

3 13