October 2008 - 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

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] Backported sbxfi driver (UNTESTED!)
by Takashi Iwai 12 Jun '09

12 Jun '09

Hi, $SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches. If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball. (I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.) The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script. **NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible. There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all. Any test- (and better debugging-) reports are appreciated. thanks, Takashi

16 112

[alsa-devel] Roland/Edirol M-16DX
by Lasse Kärkkäinen 01 Jun '09

01 Jun '09

This device doesn't seem to be supported yet. Does Roland make the specifications available, etc? The device is not compatible with USB Audio, but rather uses Vendor Specific Class. lsusb -vvv is attached below and if you need more information, I can debug the device on Linux and on Vista. Bus 007 Device 025: ID 0582:00c4 Roland Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x00c4 bcdDevice 0.00 iManufacturer 1 EDIROL iProduct 2 M-16DX iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 167 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 80 bb 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 12 04 18 01 80 bb 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x01f8 1x 504 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 3 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 3 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1

4 10

[alsa-devel] PCM delay compensation
by Takashi Iwai 23 Feb '09

23 Feb '09

Hi, the patch below (to the latest sound git tree) adds the extra delay count for USB-audio driver. This change will appear as the return value of snd_pcm_delay(). Could you check whether it's appropriate behavior you've wanted? thanks, Takashi diff --git a/include/sound/pcm.h b/include/sound/pcm.h index 40c5a6f..dcbdc60 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -269,6 +269,7 @@ struct snd_pcm_runtime { snd_pcm_uframes_t avail_max; snd_pcm_uframes_t hw_ptr_base; /* Position at buffer restart */ snd_pcm_uframes_t hw_ptr_interrupt; /* Position at interrupt time*/ + snd_pcm_sframes_t delay; /* extra delay; typically FIFO size */ /* -- HW params -- */ snd_pcm_access_t access; /* access mode */ diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index e61e125..df7c3fa 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -597,14 +597,15 @@ int snd_pcm_status(struct snd_pcm_substream *substream, if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { status->avail = snd_pcm_playback_avail(runtime); if (runtime->status->state == SNDRV_PCM_STATE_RUNNING || - runtime->status->state == SNDRV_PCM_STATE_DRAINING) + runtime->status->state == SNDRV_PCM_STATE_DRAINING) { status->delay = runtime->buffer_size - status->avail; - else + status->delay += runtime->delay; + } else status->delay = 0; } else { status->avail = snd_pcm_capture_avail(runtime); if (runtime->status->state == SNDRV_PCM_STATE_RUNNING) - status->delay = status->avail; + status->delay = status->avail + runtime->delay; else status->delay = 0; } @@ -2423,6 +2424,7 @@ static int snd_pcm_delay(struct snd_pcm_substream *substream, n = snd_pcm_playback_hw_avail(runtime); else n = snd_pcm_capture_avail(runtime); + n += runtime->delay; break; case SNDRV_PCM_STATE_XRUN: err = -EPIPE; diff --git a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c index 6e70ba4..7d5a103 100644 --- a/sound/usb/usbaudio.c +++ b/sound/usb/usbaudio.c @@ -629,6 +629,7 @@ static int prepare_playback_urb(struct snd_usb_substream *subs, subs->hwptr_done += offs; if (subs->hwptr_done >= runtime->buffer_size) subs->hwptr_done -= runtime->buffer_size; + runtime->delay += offs; spin_unlock_irqrestore(&subs->lock, flags); urb->transfer_buffer_length = offs * stride; if (period_elapsed) @@ -638,12 +639,20 @@ static int prepare_playback_urb(struct snd_usb_substream *subs, /* * process after playback data complete - * - nothing to do + * - decrease the delay count again */ static int retire_playback_urb(struct snd_usb_substream *subs, struct snd_pcm_runtime *runtime, struct urb *urb) { + unsigned long flags; + int stride = runtime->frame_bits >> 3; + int processed = urb->transfer_buffer_length / stride; + + spin_lock_irqsave(&subs->lock, flags); + if (processed > runtime->delay) + runtime->delay -= processed; + spin_unlock_irqrestore(&subs->lock, flags); return 0; } @@ -1542,6 +1551,7 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream) subs->hwptr_done = 0; subs->transfer_done = 0; subs->phase = 0; + runtime->delay = 0; /* clear urbs (to be sure) */ deactivate_urbs(subs, 0, 1);

2 6

[alsa-devel] Issue with Alsa and PulseAudio
by Ash 11 Feb '09

11 Feb '09

Hello, I have a media application that uses alsa as its sound renderer. It has worked on numerous systems without any problems until I came across a mandriva distro that bundles with PulseAudio. The alsa pulseaudio plugin is installed correctly, however I am having weird problems. When I am setting up my hw params, and I call snd_pcm_hw_params_any(), I get an "Operation not permitted" error. I am not sure why this is happening, anyone else see this before? I am using pulseaudio version 0.9.9 and alsa 1.0.16. Thanks in advance! _________________________________________________________________ Be the filmmaker you always wanted to be—learn how to burn a DVD with Windows®. http://clk.atdmt.com/MRT/go/108588797/direct/01/

4 8

[alsa-devel] (no subject)
by Philippe CARRIERE 29 Jan '09

29 Jan '09

Hi, following is a report of some tests of alsa.1.0.18rc3 in view of support of Tascam US-122L, which might be of interest for you. As a preliminary information, note that I patched my own Fedora kernel and alsa-plugins with Karsten Wiese'patches a few month ago and use regularly Tascam US-122L under Linux which works very fine; I also provide (experimental) packages for Fedora 9 from june 2008 on my web page. Test 1: succeeded - replacement of my own alsa-plugins-usb_stream-1.0.16-4.us122lv05.fc9 by alsa-plugins-usbstream-1.0.18-1.rc3.fc10 on Fedora 9 (using my own patched kernel 2.6.26 including the snd-usb-us122l module). Everything works. Test 2: succeeded - replacement of previous alsa-1.0.16 by alsa.1.0.18-1.rc3 (Fedora packages; thus alsa-driver-1.0.18rc3 not included). Everything works, including Tascam US-122L when using my patched kernel (which includes the snd-usb-us122l module). Test 3: failed - installation of alsa-driver-1.0.18rc3 (succeeded) on Fedora 9 (as weel, I tested with new Fedora 10 beta which includes kernel 2.6.27.rc3); plug in the US-122L leads to error messages from snd-usb-us122l: # cat /var/log/messages ... Oct 11 09:21:51 pollux kernel: usb 2-6: new high speed USB device using ehci_hcd and address 3 Oct 11 09:21:51 pollux kernel: usb 2-6: config 1 interface 1 altsetting 1 bulk endpoint 0x83 has invalid maxpacket 9 Oct 11 09:21:51 pollux kernel: usb 2-6: configuration #1 chosen from 1 choice Oct 11 09:21:51 pollux kernel: usb 2-6: New USB device found, idVendor=0644, idProduct=800e Oct 11 09:21:51 pollux kernel: usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 11 09:21:51 pollux kernel: usb 2-6: Product: US-122L Oct 11 09:21:51 pollux kernel: usb 2-6: Manufacturer: TASCAM Oct 11 09:21:51 pollux kernel: usb 2-6: SerialNumber: no serial number Oct 11 09:21:51 pollux kernel: ALSA /home/Test/alsa-driver-1.0.18rc3/usb/usx2y/../../alsa-kernel/usb/usx2y/usb_stream.c:618: 0 Oct 11 09:21:55 pollux kernel: ALSA /home/Test/alsa-driver-1.0.18rc3/usb/usx2y/../../alsa-kernel/usb/usx2y/us122l.c:329: us122l_start error -14 Oct 11 09:21:55 pollux kernel: snd-usb-us122l: probe of 2-6:1.1 failed with error -5 Oct 11 09:21:55 pollux kernel: usbcore: registered new interface driver snd-usb-us122l and # cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfebfc000 irq 21 US-122L finally not being recognized. Test 4: succeded - same than test 3 for Fedora 9, but using a patched ehci-hcd module (the patch adding some features from the original one by Karsten Wiese not - yet ? - included in kernel 2.6.26). Everything works including of course the US-122L. Question: Thus, a patched ehci-hcd module is required. Is the patch scheduled to appear in kernel 2.6.27 or would it be useful to work for providing a kind of kmod ? Regards Phil. -- Philippe Carriere <philippe-f.carriere(a)wanadoo.fr>

3 6

[alsa-devel] snd_pcm_set_params() bug?
by Christian Morales Vega 26 Jan '09

26 Jan '09

This code: #include <alsa/asoundlib.h> int main(){ snd_pcm_t *handle; if(snd_pcm_open(&handle, "default:1", SND_PCM_STREAM_PLAYBACK, 0) < 0) { exit(1); } if(snd_pcm_set_params(handle, SND_PCM_FORMAT_S16_LE, SND_PCM_ACCESS_RW_INTERLEAVED, 2, 24000, 1, 100000) < 0) { exit(2); } } fails with error "ALSA lib pcm.c:7193:(snd_pcm_set_params) Unable to get period size for PLAYBACK: Invalid argument" Disable resampling and you get "ALSA lib pcm.c:7142:(snd_pcm_set_params) Rate doesn't match (requested 24000Hz, get 0Hz)" (normal, I suppose). With other samplerates works fine. I'm using alsa-driver-kmp-default-1.0.16.20080602 and alsa-1.0.16.hg20080510 RPM packages from multimedia:audio openSUSE Build Service repository (from Takashi Iwai) and an AD1988 (hda-intel) codec. A XUbuntu user also has the same problem with an hda-intel codec (that I suppose uses stable 1.0.16). With a SB Live! in the same computer there are no problems. This was discovered with bsnes ( http://byuu.cinnamonpirate.com/bsnes/ - http://board.zsnes.com/phpBB2/viewtopic.php?t=11584 ) that can use openal, libao or alsa directly. The problem just happens when using 24KHz with alsa. So I suppose the problem is in the snd_pcm_set_params() itself, since openal and libao have not the problem but they set parameters "manually", not with snd_pcm_set_params().

3 2

[alsa-devel] snd_pcm_avail_update() needed before snd_pcm_delay() with hda-intel
by Christian Morales Vega 24 Jan '09

24 Jan '09

snd_pcm_avail_update() documentation says: "Using of this function is useless for the standard read/write operations. Use it only for mmap access. See to snd_pcm_delay." snd_pcm_delay() documentation says: "Note this function does not update the actual r/w pointer for applications. The function snd_pcm_avail_update() have to be called before any begin+commit operation." My english is far from perfect, and so the problem can be that I missunderstood the docs but: 1- "Using of this function"? Should not be "Use of this function"? 2- Is snd_pcm_avail_update() really useless when not using mmap? I have a SB Live! where snd_pcm_delay() always returns the correct value, without any need for snd_pcm_avail_update(). But the same code in the same machine with an hda-intel AD1988 needs a call to snd_pcm_avail_update() before snd_pcm_delay() to give the correct result. Without it snd_pcm_delay() always returns the value that *was* correct in the last snd_pcm_writei() call. So should the "application frame position" be always updated, or only in read/write operations? In the first case AD1988 fails, in the second case perhaps SB Live! is making too mucho work ;-)

4 9