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

[alsa-devel] Error patching file pcm_native.c
by Delusion's Master 20 Nov '24

20 Nov '24

Hi, first of all I apologize in case you receive multiple copies of this message, but I forgot to specify a subject in the original mail. I have a problem compiling the latest alsa driver snapshots. Specifically, it's a problem when patching pcm_native.c: [..] copying file alsa-kernel/core/info.c patching file info.c copying file alsa-kernel/core/pcm.c patching file pcm.c Hunk #3 succeeded at 739 (offset 2 lines). Hunk #5 succeeded at 954 (offset 2 lines). Hunk #7 succeeded at 1045 (offset 2 lines). copying file alsa-kernel/core/pcm_native.c patching file pcm_native.c Hunk #4 succeeded at 1544 (offset -25 lines). Hunk #5 succeeded at 2827 (offset 12 lines). Hunk #6 succeeded at 2878 (offset 10 lines). Hunk #7 FAILED at 2906. Hunk #8 FAILED at 2922. Hunk #9 succeeded at 2915 (offset -23 lines). Hunk #10 succeeded at 3036 (offset 10 lines). Hunk #11 succeeded at 3027 (offset -23 lines). Hunk #12 succeeded at 3074 (offset 10 lines). Hunk #13 succeeded at 3098 (offset -23 lines). Hunk #14 succeeded at 3143 (offset 10 lines). Hunk #15 succeeded at 3124 (offset -23 lines). Hunk #16 succeeded at 3214 (offset 10 lines). Hunk #17 succeeded at 3208 (offset -23 lines). Hunk #18 succeeded at 3271 (offset 10 lines). Hunk #19 succeeded at 3304 (offset -23 lines). Hunk #20 succeeded at 3386 (offset 10 lines). Hunk #21 succeeded at 3411 (offset -23 lines). Hunk #22 succeeded at 3456 (offset 10 lines). Hunk #23 succeeded at 3450 (offset -23 lines). Hunk #24 succeeded at 3525 (offset 10 lines). Hunk #25 succeeded at 3644 (offset -23 lines). 2 out of 25 hunks FAILED -- saving rejects to file pcm_native.c.rej make[2]: *** [pcm_native.c] Error 1 It's some days I get this, but I waited to report this since I thought it could be a temporary problem. My OS is Fedora 11 x86_64. Previous snapshots didn't give me this problem, but I can't say which one broke the compilation, since I usually try updated snapshots only at kernel updates. I searched for this error and the only relevant report I could find is this one: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016420.html a report from last April. What could the problem be? Thanks _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

3 10

[alsa-devel] hda-intel missing mixer channels
by Orm Finnendahl 26 Aug '13

26 Aug '13

Hi, I sent this to alsa-user a week ago but didn't get any reply. Does anybody know, what is responsible for the missing faders? Did the driver change or is it some module loading mechanism in the distro which prevents the faders from showing up in alsamixer? This is so strange. Please help! -- Orm -------------------------------------------------------------------- Hi everybody, after the last update of Ubuntu (intrepid to jaunty) on my Lenovo Ideapad my microphone input doesn't work anymore (neither internal nor external). I found out that alsamixer lacks quite a lot of faders in the newer kernel/module compared to the older one. Some of the faders now unavailable were crucial for Mic input to work on the older system so I'd very much like to get them back ;-) Some more infos: Soundcard: Intel 82801G (ICH7 Family) Chip: Realtek ALC269 Module: snd_hda_intel (in both kernels) Older kernel: Ubuntu stock 2.6.27-14-generic Newer kernel: Ubuntu stock 2.6.28-13-rt Is there any way to make the missing controls available or did the driver change and I have to compile the older driver for the new kernel? Yours, Orm

2 3

[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

[alsa-devel] davinci-i2c,pcm updates
by Troy Kisky 27 Sep '10

27 Sep '10

This patch set is against git://git.alsa-project.org/alsa-kernel.git but the last patch in series won't compile until the sram allocator patch is available.

8 44

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] snd-hda-intel: no data when recording from mic, "IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj" logged in kern.log
by Aleksander Adamowski 17 Mar '10

17 Mar '10

Hi! I think I have some interesting problems to analyse for Takashi. Maybe my sound card model is a non typical one, but I have a continuous stream of capture-related problems with it. It's an integrated sound card on my Gigabyte GA-MA74GM-S2H Rev. 1.1 motherboard. "grep ^Codec /proc/asound/card0/codec#0" shows: Codec: Realtek ALC888 I'm attaching the full contents of /proc/asound/card0/codec#0 for identification. But first, some background. With this particular card, I've been continuously hit by the "azx_get_response timeout, switching to single_cmd mode" problem, described here: http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_cod… However, in my case setting probe_mask=1 (experimentally determined) didn't make the problem go away, although it seemed to reduce its frequency (might be just a coincidence). Whenever the dreaded "azx_get_response timeout, switching to single_cmd mode" message appeared in the kernel log, recording stopped working. The card got into the bad state where it would not record sound, and arecord would be giving a stream of "overrun" error messages: arecord -f cd output.wav Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo overrun!!! (at least 27.876 ms long) overrun!!! (at least 26.965 ms long) overrun!!! (at least 16.169 ms long) overrun!!! (at least 11.749 ms long) overrun!!! (at least 11.298 ms long) overrun!!! (at least 11.814 ms long) overrun!!! (at least 11.190 ms long) overrun!!! (at least 11.190 ms long) overrun!!! (at least 11.747 ms long) overrun!!! (at least 11.819 ms long) overrun!!! (at least 11.149 ms long) overrun!!! (at least 11.257 ms long) overrun!!! (at least 11.315 ms long) overrun!!! (at least 11.651 ms long) overrun!!! (at least 11.745 ms long) overrun!!! (at least 11.235 ms long) overrun!!! (at least 11.169 ms long) overrun!!! (at least 11.776 ms long) overrun!!! (at least 11.391 ms long) overrun!!! (at least 11.669 ms long) overrun!!! (at least 11.714 ms long) overrun!!! (at least 11.671 ms long) overrun!!! (at least 11.190 ms long) What's notable, sound playback would continue to work OK. After being fed up with interrupted Skype conversations (where I weren't immediately aware that the other side stopped hearing me, since I was hearing them), I've decided to upgrade do kernel 2.6.29 (citing the http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_cod… document: "Since 2.6.29 kernel, the driver has a more robust probing method, so this error might happen rarely, though"). After upgrading to 2.6.29 I've removed any extra snd-hda-intel options from modprobe config files. Now the azx_get_response timeout seems to be gone, but I'm experiencing another problem: after some powered up time, recording starts giving empty streams - there's no error, but audio data has zero lengh. e.g. when I arecord, I get a .wav file that is only 44 bytes long (which seems to be the length of the WAV header). When I make a Skype test call to echo123, and it starts playing back my message, it's zero length too - the playback end signal can be heard immediately after the playback start signal. This problem seems to concide with the following error message in the kernel log: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. Do you have any idea what could be the cause and how to debug this issue further? -- Best Regards, Aleksander Adamowski http://olo.org.pl

2 10

[alsa-devel] [PATCH] ARM: DaVinci: Audio support for DA850/OMAP-L138 EVM
by Chaithrika U S 20 Jan '10

20 Jan '10

Define resources for McASP used on DA850/OMAP-L138 EVM, add platform device defintion and Pin Mux configurations. Signed-off-by: Chaithrika U S <chaithrika(a)ti.com> --- Applies on DaVinci GIT tree. This patch is dependent on the following patch which I have submitted earlier: [PATCH v2] ARM: DaVinci: Audio support for DA830 EVM arch/arm/mach-davinci/board-da850-evm.c | 29 ++++++++++++++++++++++ arch/arm/mach-davinci/da850.c | 39 ++++++++++++++++++++++++++++++ arch/arm/mach-davinci/devices-da8xx.c | 34 +++++++++++++++++++++++++- arch/arm/mach-davinci/include/mach/asp.h | 7 +++++ arch/arm/mach-davinci/include/mach/mux.h | 25 +++++++++++++++++++ 5 files changed, 133 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index d989346..52bfe4c 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -38,6 +38,28 @@ static struct davinci_uart_config da850_evm_uart_config __initdata = { .enabled_uarts = 0x7, }; +/* davinci da850 evm audio machine driver */ +static u8 da850_iis_serializer_direction[] = { + INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, + INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, + INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, TX_MODE, + RX_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, +}; + +static struct snd_platform_data da850_evm_snd_data = { + .tx_dma_offset = 0x2000, + .rx_dma_offset = 0x2000, + .op_mode = DAVINCI_MCASP_IIS_MODE, + .num_serializer = ARRAY_SIZE(da850_iis_serializer_direction), + .tdm_slots = 2, + .serial_dir = da850_iis_serializer_direction, + .eventq_no = EVENTQ_1, + .version = MCASP_VERSION_2, + .txnumevt = 1, + .rxnumevt = 1, +}; + + static __init void da850_evm_init(void) { struct davinci_soc_info *soc_info = &davinci_soc_info; @@ -86,6 +108,13 @@ static __init void da850_evm_init(void) */ __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30); __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30); + + ret = da8xx_pinmux_setup(da850_mcasp_pins); + if (ret) + pr_warning("da850_evm_init: mcasp mux setup failed: %d\n", + ret); + + da8xx_init_mcasp(0, &da850_evm_snd_data); } #ifdef CONFIG_SERIAL_8250_CONSOLE diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 4a43ae2..e33b226 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -289,6 +289,13 @@ static struct clk emac_clk = { .lpsc = DA8XX_LPSC1_CPGMAC, }; +static struct clk mcasp_clk = { + .name = "mcasp", + .parent = &pll0_sysclk2, + .lpsc = DA8XX_LPSC1_McASP0, + .psc_ctlr = 1, +}; + static struct davinci_clk da850_clks[] = { CLK(NULL, "ref", &ref_clk), CLK(NULL, "pll0", &pll0_clk), @@ -326,6 +333,7 @@ static struct davinci_clk da850_clks[] = { CLK(NULL, "arm", &arm_clk), CLK(NULL, "rmii", &rmii_clk), CLK("davinci_emac.1", NULL, &emac_clk), + CLK("davinci-mcasp.0", NULL, &mcasp_clk), CLK(NULL, NULL, NULL), }; @@ -370,6 +378,30 @@ static const struct mux_config da850_pins[] = { MUX_CFG(DA850, MII_RXD_2, 3, 20, 15, 8, false) MUX_CFG(DA850, MII_RXD_1, 3, 24, 15, 8, false) MUX_CFG(DA850, MII_RXD_0, 3, 28, 15, 8, false) + /* McASP function */ + MUX_CFG(DA850, ACLKR, 0, 0, 15, 1, false) + MUX_CFG(DA850, ACLKX, 0, 4, 15, 1, false) + MUX_CFG(DA850, AFSR, 0, 8, 15, 1, false) + MUX_CFG(DA850, AFSX, 0, 12, 15, 1, false) + MUX_CFG(DA850, AHCLKR, 0, 16, 15, 1, false) + MUX_CFG(DA850, AHCLKX, 0, 20, 15, 1, false) + MUX_CFG(DA850, AMUTE, 0, 24, 15, 1, false) + MUX_CFG(DA850, AXR_15, 1, 0, 15, 1, false) + MUX_CFG(DA850, AXR_14, 1, 4, 15, 1, false) + MUX_CFG(DA850, AXR_13, 1, 8, 15, 1, false) + MUX_CFG(DA850, AXR_12, 1, 12, 15, 1, false) + MUX_CFG(DA850, AXR_11, 1, 16, 15, 1, false) + MUX_CFG(DA850, AXR_10, 1, 20, 15, 1, false) + MUX_CFG(DA850, AXR_9, 1, 24, 15, 1, false) + MUX_CFG(DA850, AXR_8, 1, 28, 15, 1, false) + MUX_CFG(DA850, AXR_7, 2, 0, 15, 1, false) + MUX_CFG(DA850, AXR_6, 2, 4, 15, 1, false) + MUX_CFG(DA850, AXR_5, 2, 8, 15, 1, false) + MUX_CFG(DA850, AXR_4, 2, 12, 15, 1, false) + MUX_CFG(DA850, AXR_3, 2, 16, 15, 1, false) + MUX_CFG(DA850, AXR_2, 2, 20, 15, 1, false) + MUX_CFG(DA850, AXR_1, 2, 24, 15, 1, false) + MUX_CFG(DA850, AXR_0, 2, 28, 15, 1, false) #endif }; @@ -406,6 +438,13 @@ const short da850_cpgmac_pins[] __initdata = { -1 }; +const short da850_mcasp_pins[] __initdata = { + DA850_AHCLKX, DA850_ACLKX, DA850_AFSX, + DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE, + DA850_AXR_11, DA850_AXR_12, + -1 +}; + /* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */ static u8 da850_default_priorities[DA850_N_CP_INTC_IRQ] = { [IRQ_DA8XX_COMMTX] = 7, diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index fe0baaf..1882eef 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -309,6 +309,34 @@ static struct platform_device da830_mcasp1_device = { .resource = da830_mcasp1_resources, }; +static struct resource da850_mcasp_resources[] = { + { + .name = "mcasp", + .start = DAVINCI_DA8XX_MCASP0_REG_BASE, + .end = DAVINCI_DA8XX_MCASP0_REG_BASE + (SZ_1K * 12) - 1, + .flags = IORESOURCE_MEM, + }, + /* TX event */ + { + .start = DAVINCI_DA8XX_DMA_MCASP0_AXEVT, + .end = DAVINCI_DA8XX_DMA_MCASP0_AXEVT, + .flags = IORESOURCE_DMA, + }, + /* RX event */ + { + .start = DAVINCI_DA8XX_DMA_MCASP0_AREVT, + .end = DAVINCI_DA8XX_DMA_MCASP0_AREVT, + .flags = IORESOURCE_DMA, + }, +}; + +static struct platform_device da850_mcasp_device = { + .name = "davinci-mcasp", + .id = 0, + .num_resources = ARRAY_SIZE(da850_mcasp_resources), + .resource = da850_mcasp_resources, +}; + int __init da8xx_register_emac(void) { return platform_device_register(&da8xx_emac_device); @@ -316,8 +344,12 @@ int __init da8xx_register_emac(void) void __init da8xx_init_mcasp(int id, struct snd_platform_data *pdata) { - if (id == 1) { /* DA830/OMAP-L137 has 3 instances of McASP */ + /* DA830/OMAP-L137 has 3 instances of McASP */ + if (cpu_is_davinci_da830() && id == 1) { da830_mcasp1_device.dev.platform_data = pdata; platform_device_register(&da830_mcasp1_device); + } else if (cpu_is_davinci_da850()) { + da850_mcasp_device.dev.platform_data = pdata; + platform_device_register(&da850_mcasp_device); } } diff --git a/arch/arm/mach-davinci/include/mach/asp.h b/arch/arm/mach-davinci/include/mach/asp.h index f3c97ac..18e4ce3 100644 --- a/arch/arm/mach-davinci/include/mach/asp.h +++ b/arch/arm/mach-davinci/include/mach/asp.h @@ -15,6 +15,9 @@ #define DAVINCI_DM646X_MCASP0_REG_BASE 0x01D01000 #define DAVINCI_DM646X_MCASP1_REG_BASE 0x01D01800 +/* Bases of da850/da830 McASP0 register banks */ +#define DAVINCI_DA8XX_MCASP0_REG_BASE 0x01D00000 + /* Bases of da830 McASP1 register banks */ #define DAVINCI_DA830_MCASP1_REG_BASE 0x01D04000 @@ -29,6 +32,10 @@ #define DAVINCI_DM646X_DMA_MCASP0_AREVT0 9 #define DAVINCI_DM646X_DMA_MCASP1_AXEVT1 12 +/* EDMA channels of da850/da830 McASP0 */ +#define DAVINCI_DA8XX_DMA_MCASP0_AREVT 0 +#define DAVINCI_DA8XX_DMA_MCASP0_AXEVT 1 + /* EDMA channels of da830 McASP1 */ #define DAVINCI_DA830_DMA_MCASP1_AREVT 2 #define DAVINCI_DA830_DMA_MCASP1_AXEVT 3 diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h index a676b2f..f50f5b2 100644 --- a/arch/arm/mach-davinci/include/mach/mux.h +++ b/arch/arm/mach-davinci/include/mach/mux.h @@ -748,6 +748,31 @@ enum davinci_da850_index { DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, + + /* McASP function */ + DA850_ACLKR, + DA850_ACLKX, + DA850_AFSR, + DA850_AFSX, + DA850_AHCLKR, + DA850_AHCLKX, + DA850_AMUTE, + DA850_AXR_15, + DA850_AXR_14, + DA850_AXR_13, + DA850_AXR_12, + DA850_AXR_11, + DA850_AXR_10, + DA850_AXR_9, + DA850_AXR_8, + DA850_AXR_7, + DA850_AXR_6, + DA850_AXR_5, + DA850_AXR_4, + DA850_AXR_3, + DA850_AXR_2, + DA850_AXR_1, + DA850_AXR_0, }; #ifdef CONFIG_DAVINCI_MUX -- 1.5.6

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