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

Re: [alsa-devel] a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card
by Robert Hancock 27 Feb '08

27 Feb '08

Avuton Olrich wrote: > With v2.6.24 my second ALSA sound device stopped working. > > After bisection it says this was the offending commit. > > a7839e960675b549f06209d18283d5cee2ce9261 is first bad commit > commit a7839e960675b549f06209d18283d5cee2ce9261 > Author: Zhao Yakui <yakui.zhao(a)intel.com> > Date: Wed Nov 28 16:21:21 2007 -0800 > > PNP: increase the maximum number of resources > > On some systems the number of resources(IO,MEM) returnedy by PNP device is > greater than the PNP constant, for example motherboard devices. It brings > that some resources can't be reserved and resource confilicts. This will > cause PCI resources are assigned wrongly in some systems, and cause hang. > This is a regression since we deleted ACPI motherboard driver and use PNP > system driver. > > [akpm(a)linux-foundation.org: fix text and coding-style a bit] > Signed-off-by: Li Shaohua <shaohua.li(a)intel.com> > Signed-off-by: Zhao Yakui <yakui.zhao(a)intel.com> > Cc: Bjorn Helgaas <bjorn.helgaas(a)hp.com> > Cc: Thomas Renninger <trenn(a)suse.de> > Cc: <stable(a)kernel.org> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> > > The audio device is 00:1b.0 (see my lspci -vvv output), the other > audio device works fine. > > http://avuton.googlepages.com/v2.6-before (dmesg revision before) > http://avuton.googlepages.com/v2.6-after (dmesg broken revision) > http://avuton.googlepages.com/lspci-vvv > http://avuton.googlepages.com/config (from the broken revision) > http://avuton.googlepages.com/iomem > http://avuton.googlepages.com/ioports Here's why the driver fails to load: [ 31.133060] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 [ 31.133141] PCI: Unable to reserve mem region #1:4000@febf8000 for device 0000:00:1b.0 [ 31.133197] ACPI: PCI interrupt for device 0000:00:1b.0 disabled [ 31.133244] HDA Intel: probe of 0000:00:1b.0 failed with error -16 The iomem location of the HDA controller conflicts with this reservation by the BIOS: [ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved There was a patch floating around to ignore PnPACPI reservations which conflict with PCI BARs, which appears to be what's happening in this case. That patch originally worked for any board, but was later made specific to a certain Supermicro motherboard which had the sata_nv controller MMIO regions marked as reserved, preventing the driver from loading. We may need a more general solution. See: https://bugzilla.redhat.com/show_bug.cgi?id=313491

5 24

[alsa-devel] HDMI Multichannel LPCM/RAW Support/Status
by Dustin Kerstein 27 Feb '08

27 Feb '08

I was just curious if there is any planned support for multichannel LPCM/Raw audio for newer HDMI based chipsets. There are several matx boards with HDMI 1.1 and above compliance, which means they should be able to pass 8-channel LPCM audio. Also, in HDMI 1.3 and above, Bit Stream passing is supported, which actually should be easier, bandwidth wise, than LPCM. Multichannel PCM (above 2 channels) was never an issue because SPDIF lacked the bandwidth. After talking with some people in irc it seems as though the # of channels setting in Alsa is only one bit. Thanks. Dustin

2 2

Re: [alsa-devel] PATCH for alsa-info.sh - using mktemp for instead of hardcoded temp dir.
by Takashi Iwai 27 Feb '08

27 Feb '08

At Thu, 28 Feb 2008 02:42:20 +1000, Travis Place wrote: > > On Thu, 28 Feb 2008 2:39:16 am you wrote: > > At Thu, 28 Feb 2008 00:36:52 +1000, > > > > Travis Place wrote: > > > Email subject should explain well enough. > > > > I see some problems with this change: > > - it doesn't work if /tmp/alsainfo doesn't exist > > - temp directory isn't removed if --no-upload is given > > > > I think you should avoid --tempdir=xxx with mktemp. > > > > The output file name is another question. > > IMO, it'd be better to pass the output file name via a command line > > option, and put it on the home directory (e.g. ~/alsa-info.out) as > > default rather than /tmp. > > well, /tmp/alsainfo/ will exist, as we create it in the script.. its > $ALSAINFODIR .. the temp dir is then created inside that. It's created too late. And, if we create /tmp/alsainfo, there is little merit of mktemp as /tmp/alsainfo could be a symlink. Simply TEMPDIR should be what mktemp creates, and clean it up after quitting. > As for not being cleaned up, if --no-upload is specified, ill check that now.. > > Also, is outputting the resulting file to ~/ wise ? It's at least safer than the fixed filename on /tmp. I don't insist on this option, though. Anyway, --output-file=xxx would be a nice addition. > should this occur even if the result is uploaded, or only on > --no-upload ? I don't think it's needed when uploaded (except for any debugging reason). Just my $0.02. thanks, Takashi

2 1

[alsa-devel] PATCH for alsa-info.sh - using mktemp for instead of hardcoded temp dir.
by Travis Place 27 Feb '08

27 Feb '08

Email subject should explain well enough. -- Happiness is like peeing your pants. Everyone can see it, but only you can feel its warmth

2 2

[alsa-devel] new driver: channel alignment (was: 30mS interval problem)
by William Juul 27 Feb '08

27 Feb '08

Hello I am new to ALSA and trying to write a new driver for a ADC connected with PCM to an AVR32 on a NGW100 reference card provided by Atmel. I have the problem that different channels from the PCM stream comes in different positions in the WAV file. For example when I disable all but the first PCM channel on the ADC, I can see with an oscilloscope that there is only data in the first timeslot on the PCM data stream. But the data from this channel can occur in any of the 4 channels in the WAV file. This is consistent throughout the one capture/file, but in the next capture the data will occur in another channel in the WAV-file. How can I make sure that the data from one particular channel always occur in a fixed position in the WAV file? Best regards William Juul

1 0

[alsa-devel] [ALC262 patch_realtek.c] Add Fujitsu Lifebook E8410 to quirk table
by Tony Vroon 27 Feb '08

27 Feb '08

Good afternoon, Could you please consider the following patch for 2.6.25-rc4. The BIOS autoprobe doesn't do a very good job setting this card up. Card details: 00:1b.0 0403: 8086:284b (rev 03) Subsystem: 10cf:142d (and verbose codec information attached) Regards, Tony V. LINX sysadmin

3 2

Re: [alsa-devel] Ends up with write error (Ning Zhang)
by Ning Zhang 27 Feb '08

27 Feb '08

Hi all, There is no response so far, maybe I am not clear. So in sum, here are the questions: 1. In meddle-level driver, how comes the runtime->control->avail_min? I mean which function set the value, and according what to set the value? Does it have some relationship to the hardware configuration in the device driver( i.e snd_pcm_hardware )? 2. Should I use the snd_pcm_period_elapsed function even I don't use the interrupt mechanism? If yes, In which callback function should I call it(snd_pcm_period_elapsed)? 3,Can anybody do me a favor to explain the mechanism of the middle-level driver or give me some hints? Thanks in advance. BRs, David > > ------------------------------ > > Message: 7 > Date: Wed, 20 Feb 2008 16:30:54 +0800 > From: "Ning Zhang" <ning.zhang06(a)gmail.com> > Subject: [alsa-devel] Ends up with write error > To: alsa-devel <alsa-devel(a)alsa-project.org> > Message-ID: > <48a1cba90802200030v65794b96j7c956406fdc0df9c(a)mail.gmail.com> > Content-Type: text/plain; charset=GB2312 > > Hi all, > I am writing a ALSA driver for my ARM 926 platform. The ARM communicates > with the DSP by accessing a 128-byte shared memory. I don't use IRQ > mechanism.(In fact, I am not sure the platform has this mechanism) > Here is some code slices: > > static struct snd_pcm_hardware snd_arch_playback_hw = { > > .info = (SNDRV_PCM_INFO_MMAP | > > SNDRV_PCM_INFO_INTERLEAVED | > > SNDRV_PCM_INFO_BLOCK_TRANSFER), > > .formats = SNDRV_PCM_FMTBIT_S16_LE, > > .rates = (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 |\ > > SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |\ > > SNDRV_PCM_RATE_48000), > > .rate_min = 8000, > > .rate_max = 48000, > > .channels_min = 2, > > .channels_max = 2, > > .buffer_bytes_max = 128, > > .period_bytes_min = 2, > > .period_bytes_max = 128, > > .periods_min = 1, > > .periods_max = 64, > > }; > > > > static snd_pcm_uframes_t snd_arch_pcm_pointer(struct snd_pcm_substream > > *substream) > > { ? > > /* > > * get the current hardware pointer > > */ > > current_ptr = arch_fw_read_dsp_reg(chip, AFE_RWADDR) & AFE_RD_ADDR; > > > return bytes_to_frames(runtime, current_ptr); > > } > > static int snd_arch_pcm_playback_copy(struct snd_pcm_substream *substream, > > int channel, > > snd_pcm_uframes_t pos, > > void __user *src, > > snd_pcm_uframes_t count) > > { ?? > > > > count = frames_to_bytes(runtime, count); > > pos = frames_to_bytes(runtime, pos); > > chip->bufpos = pos; > > ?. > > spin_lock(chip->reg_lock); > > if ( count > 0 && count <= MAX_BUF_SIZE ) { > > if ( copy_from_user(chip->bufptr, src, count) ) { > > snd_printk(KERN_ERR "can not copy user data!\n"); > > return -EFAULT; > > } > > if ( arch_fill_rx_buf(chip, > > (signed short*)(chip->bufptr), > count) < 0 ) { > > snd_printk(KERN_ERR "fill rx buffer failed!\n"); > > return -1; > > } > > ????? > > } > spin_unlock(chip->reg_lock); > > return 0; > > } > > The problem is my driver can make sounds, but ends up a write > error. After > much debugging, I think there might be some problem in the > interworking between > middle-level driver and the device driver. > > I found the runtime->control->avail_min=32, and the > runtime->buffer_size and runtime->period_size are both 32. So at first > middle-level driver call snd_pcm_lib_write1 transfers 32 frames(128 bytes) > to the device driver's copy callback function and trigger function. Then > when middle-level driver wants to transfer another 32 frames, it calls the > pointer callback function and gets the position, because at this time the > whole bytes has not been processed completely, so the pointer function's > return value must less than 32, and the avail must less than > runtime->control_->avail_min, and goes to this flow and ends up a write > error. > > > _______________________________________________________________________________ > > if (((avail < runtime->control->avail_min && size > avail) || > > (size >= runtime->xfer_align && avail < > runtime->xfer_align))) { > > ?????... > > long tout; > > init_waitqueue_entry(&wait, current); > > add_wait_queue(&runtime->sleep, &wait); > > while (1) { > > if (signal_pending(current)) { > > state = SIGNALED; > > break; > > } > > set_current_state(TASK_INTERRUPTIBLE); > > snd_pcm_stream_unlock_irq(substream); > > tout = schedule_timeout(10 * HZ); > > snd_pcm_stream_lock_irq(substream); > > if (tout == 0) { > > if (runtime->status->state != > SNDRV_PCM_STATE_PREPARED && > > runtime->status->state != > SNDRV_PCM_STATE_PAUSED) { > > state = > runtime->status->state == SNDRV_PCM_STATE_SUSPENDED ? SUSPENDED : EXPIRED; > > break; > > } > > } > > switch (runtime->status->state) { > > > ????.. > > : > > state = ERROR; > > goto _end_loop; > > > > default: > > break; > > } > > avail = > snd_pcm_playback_avail(runtime); > > if (avail >= > runtime->control->avail_min) > { > > state = READY; > > break; > > } > > } > > _end_loop: > > remove_wait_queue(&runtime->sleep, &wait); > > > > switch (state) { > > ??. > > case EXPIRED: > > snd_printd("playback write error (DMA > or > IRQ trouble?)\n"); > > err = -EIO; > > goto _end_unlock; > > ??? > > } > > } > > This code is a part of snd_pcm_lib_write1() in sound/core/pcm_lib.c > > I think that I misunderstood the mechanism of middle-level driver. Could > you please correct me? > > What should the pointer callback function return? What's it for? > > How comes the runtime->control->avail_min? > > Because I don't use the IRQ, so should I use the snd_pcm_period_elapsed > function? And where? > > ALSA Version is 1.0.14rc1 and I use alsa-lib-1.0.15. > > Can someone comment on this and give me some hints to solve this > problem? Thanks > in advance. > > BRs, > > David > > ------------------------------ > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > End of Alsa-devel Digest, Vol 12, Issue 69 > ****************************************** >

2 2

Re: [alsa-devel] Via VT82xx VT1708 ICE1724HT and higher
by Demian Martin 27 Feb '08

27 Feb '08

Pavel: Thanks for the insight. I thought I was doing something wrong since no one else has noticed. I tried your suggestion to use plughw:0,1 and the verbose output looks fine, the data rate shifts fine (I'm watching the L/R clock on the input to the DAC on an external DAC) but no audible sound comes out the converter unless it's a 16 bit 44.1 file. The 24 bit stuff is not getting converted into something useful to the DAC. Should I check to see if the data clock is 48X the LR clock? What info do you need from me to look deeper? I can supply a sample clip of a 176.4 KHz recording from Reference Recordings if it would be helpful. I'm also testing with the samples from Linn and Gimmel. I looked at the Plug plugin but have not been able to figure out how to configure it for my needs. There is way too much marginal information on the web and little that directs me to an optimum setting. -Demian From: Pavel Hofman <pavel.hofman(a)insite.cz> Subject: Re: [alsa-devel] Via VT82xx VT1708 ICE1724HT and higher sample rate/bit depth files through SPDIF To: Demian Martin <demianm_1(a)yahoo.com> Cc: alsa-devel(a)alsa-project.org Message-ID: <47C423E4.4060900(a)insite.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Hi Martin, > > First- sample rate > > Even though the documents claim that it will play at 176.4 KHz and 192KHz > whenever I play a file at these rates it down converts to ? the rate (88200 > and 96000). I tested this with the ICE1724HT (Juli@) which has almost the > same core, I never could get 176.4KHz at the SPDIF output. I confirmed that > the ICE1724 will play the file at 176.4KHz in Windows so its not a hardware > limitation. I tried to do the same with the VT1708 (on a Via CX700 chipset) > and the Windows driver wouldn?t let me at anything other than 48000. I spent a few days on this issue and confirm that ICE1724HT cannot output 176.4kHz from its internal SPDIF transmitter, WHEN clocked by its internal clock circuits. A scope hooked to corresponding pins/outputs revealed the following: All I2S lines output correct 176.4kHz signal, i.e. D/A codecs receive proper signal. However, I did not find a way to force ICE1724 to output 176.4kHz, it always drops to 88.2kHz, no matter what MT01/MT02 combination is. The same happens with windows drivers of my Prodigy 192. The sequence is: 44.1, 48, 88.2, 96, 88.2, 192 I have not seen any manufacturer of Envy-based cards revealing this deficiency. The "preliminary" datasheet we all use mentions only that the chip forces the 128x mode when switched to 176.4kHz. I believe the output of 88.2kHz is an undocumented feature or perhaps even a bug of the chip. Juli is a card whose manufacturer may be aware of the problem. It is not clocked by ICE1724 internal clocks fed by the two crystals. Instead, the crystals also provide signal to external circuits generating clock signals of required frequency, feeding the chip in slave mode. The circuitry is controlled by ice1724 GPIOs. This way the ICE1724 is not aware of its clocking frequency and cannot thus mis-configure its SPDIF transmitter. The windows driver does output proper 176.4kHz. I am working on Juli driver and have been analyzing this beast for a few nights. The special clocking is already working at home :) > Second, the only way I can get the 24 bit files out in a form that the card > can play is to pass them through dmix. But I need to reconfigure dmix for > each sample rate. And I?m not convinced that it isn?t resampling twice, both > at the input and the output. Or how to configure the buffers etc. to prevent > underruns even when the only conversion is to pass a 24 bit file to the > card. ICE cards use 32bits format. Try aplay -v -D plughw:0 24bit.wav and you will see the conversion to 32 bits done by the plug plugin, no dmix involved. > > I?m trying to build a high quality music server that will pass the files to > either the internal or an external DAC at the bit depth and sample rate they > were recorded at. I have tried to understand the various plugs and settings > but it seems they are all focused on mixing various streams. I want to send > the files unmixed to the output. I can?t figure out what set of plugs and > settings in asound.conf would enable this. Check the plug plugin. Regards, Pavel Hofman. -----------------

3 2

[alsa-devel] ATI HD 2600 Sound?
by Isaac Manuel 26 Feb '08

26 Feb '08

HP Pavilion HDX9200 Laptop PC Ubuntu 7.10 (Gutsy Gibbon) Linux Kernel 2.6.22-14-generic Sound only play through headphones. *aplay -l* **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA ATI HDMI], device 0: ATI HDMI [ATI HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 *sudo lspci -v *Audio device: ATI Technologies Inc Unknown device aa08 Subsystem: Hewlett-Packard Company Unknown device 30d4 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at e8310000 (32-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint IRQ 0 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- * **sudo lspci -nv* 0403: 1002:aa08 Subsystem: 103c:30d4 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at e8310000 (32-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint IRQ 0 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-

1 0

[alsa-devel] hdsp firmware
by Karl Grill 26 Feb '08

26 Feb '08

Hi all, as a first step towards implementing support for the hdsp rpm, I've uploaded a patch to the alsa-firmware branch as bug report #3810. Besides the patch, I've put up the firmware binaries in .tar.gz format. This contains replacements for the rev.11 firmware for the digiface/multiface and also for the rpm. The latter is of little use right now, but I'd be very happy if anybody could try those for the digiface/multiface and report if it works, so I know if my assumptions on the drivers are correct. best regards kg PS. sorry I didn't file this report in the firmware section, but the web form there doesn't give me any usable choice for Category yet insists that I supply one.

1 0

[alsa-devel] Zoom H4 hand held studio.
by Joseph klitzke 26 Feb '08

26 Feb '08

Greetings I am inquiring into the development of a driver for the Zoom H4 Hand held recorder. Is there any work being done on the device? If not is it being considered. Is there anything I can do to get it started? In short the H4 can 4 track recorder and a usb audio device with effects, a great piece of recording gear. Thanks Joseph Klitzke

1 0

[alsa-devel] snd-usb-audio syncronisation problem
by Adrian Stancu 26 Feb '08

26 Feb '08

Hi, I'm using an E-MU 0404 USB interface with the snd-usb-audio module from alsa 1.0.16, operating in isochronous asynchronous mode. This interface was producing very annoying click/pop sounds at regular intervals during playback. Eventually I discovered that the syncronisation mechanism telling the driver to send audio data faster or slower to match the interface's consumption speed does not work as expected, for some reason. I did a very dirty hack within the source of this driver, simulating the interface asking for data to be sent a little bit quicker, and this almost fixed the problem *for me*. I really wish to debug this issue further, to find what actually does not work as it should in this feed-back mechanism. However this was the first time I dealt with alsa source code, so I do not have much experience. Therefore, I really need help with debugging this problem and maybe finding an universal fix. Thanks in advance, Adi

4 27

[alsa-devel] HDA-Intel - Patch to support RV7xx HDMI Audio
by Yang, Libin 26 Feb '08

26 Feb '08

Hi Takashi, This patch is to add R7xx HDMI audio support. Would you please accept it? Thanks a lot! Signed-off-by: Libin Yang <Libin.yang(a)amd.com> --- alsa-driver-1.0.16/alsa-kernel/pci/hda/hda_intel.c.orig 2008-02-13 11:57:11.000000000 -0500 +++ alsa-driver-1.0.16/alsa-kernel/pci/hda/hda_intel.c 2008-02-13 12:02:39.000000000 -0500 @@ -2015,6 +2015,9 @@ { 0x1002, 0xaa20, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RV635 HDMI */ { 0x1002, 0xaa28, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RV620 HDMI */ { 0x1002, 0xaa30, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RV770 HDMI */ + { 0x1002, 0xaa38, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RV730 HDMI */ + { 0x1002, 0xaa40, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RV710 HDMI */ + { 0x1002, 0xaa48, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_ATIHDMI }, /* ATI RV740 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 */ Thanks & Regards, Libin

3 4

[alsa-devel] Via VT82xx VT1708 ICE1724HT and higher sample rate/bit depth files through SPDIF
by Demian Martin 26 Feb '08

26 Feb '08

I have several problems trying to play files higher than 48000 KHz and with bit depth of 24 bits. I submitted this to the users and got a resounding silence. First- sample rate Even though the documents claim that it will play at 176.4 KHz and 192KHz whenever I play a file at these rates it down converts to ½ the rate (88200 and 96000). I tested this with the ICE1724HT (Juli@) which has almost the same core, I never could get 176.4KHz at the SPDIF output. I confirmed that the ICE1724 will play the file at 176.4KHz in Windows so its not a hardware limitation. I tried to do the same with the VT1708 (on a Via CX700 chipset) and the Windows driver wouldnt let me at anything other than 48000. Second, the only way I can get the 24 bit files out in a form that the card can play is to pass them through dmix. But I need to reconfigure dmix for each sample rate. And Im not convinced that it isnt resampling twice, both at the input and the output. Or how to configure the buffers etc. to prevent underruns even when the only conversion is to pass a 24 bit file to the card. Im trying to build a high quality music server that will pass the files to either the internal or an external DAC at the bit depth and sample rate they were recorded at. I have tried to understand the various plugs and settings but it seems they are all focused on mixing various streams. I want to send the files unmixed to the output. I cant figure out what set of plugs and settings in asound.conf would enable this.

2 1

[alsa-devel] [PATCH 1/3] ASoC: Fix TLV320AIC3X PLL divider table for 64 kHz rate
by Mark Brown 26 Feb '08

26 Feb '08

From: Jarkko Nikula <jarkko.nikula(a)nokia.com> Signed-off-by: Jarkko Nikula <jarkko.nikula(a)nokia.com> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/tlv320aic3x.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index 710e028..569ecac 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -681,8 +681,8 @@ static const struct aic3x_rate_divs aic3x_divs[] = { {22579200, 48000, 48000, 0x0, 8, 7075}, {33868800, 48000, 48000, 0x0, 5, 8049}, /* 64k */ - {22579200, 96000, 96000, 0x1, 8, 7075}, - {33868800, 96000, 96000, 0x1, 5, 8049}, + {22579200, 64000, 96000, 0x1, 8, 7075}, + {33868800, 64000, 96000, 0x1, 5, 8049}, /* 88.2k */ {22579200, 88200, 88200, 0x0, 8, 0}, {33868800, 88200, 88200, 0x0, 5, 3333}, -- 1.5.4.3

2 4

[alsa-devel] new driver: 30mS interval problem
by William Juul 26 Feb '08

26 Feb '08

Hello I am new to ALSA and trying to write a new driver for a DAC connected with PCM to an AVR32 on a NGW100 reference card provided by Atmel. The sampling rate I am currently using is 11047and the DAC is providing 4 channels of 24bit. The HW interface is using DMA to copy data to RAM. By studying the audio data in hexdump or in Audacity I can verify that the sound looks good in intervals of about 30mS, then all channels are garbled for 30mS. This pattern repeat itself throughout the audio capture. I am not confident I have configured all ALSA parameters properly. How can I go about fixing/debugging this 30mS intverval problem? Below is the command I am using. Best regards William Juul # arecord -r 11047 -c 4 -f S24_LE -s 1 -A 100 -d 5 --buffer-size 16384 -F 21333 -v > test.wav Recording WAVE 'stdin' : Signed 24 bit Little Endian, Rate 11047 Hz, Channels 4 Plug PCM: Hardware PCM card 0 'AVR32 NGW100 external DAC' device 0 subdevice 0 pcm->setup: 1 stream : CAPTURE access : RW_INTERLEAVED format : S24_LE subformat : STD channels : 4 rate : 11047 exact rate : 11047 (11047/1) msbits : 32 buffer_size : 16384 period_size : 490 period_time : 44355 tick_time : 4000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 490 xfer_align : 490 start_threshold : 1 stop_threshold : 16384 silence_threshold: 0 silence_size : 0 boundary : 1073741824

2 4

Re: [alsa-devel] ASoC - Output widgets
by Mark Brown 26 Feb '08

26 Feb '08

On Tue, Feb 26, 2008 at 10:11:42AM +0100, Alexandre BOUIN wrote: > DAPM WM8900 snd_soc_dapm_stream_event > FM Transmitter: On in 2 out 1 > in static FMOUT_R > in static FMOUT_L > I initialize FM Transmitter like this : > snd_soc_dapm_set_endpoint(codec, "FM Transmitter", 0); > but it still enabled. Why ? According to the above trace your FM transmitter is still reporting as being connected. Have you checked to ensure that your your call to configure the transmitter is happening after your board widgets have been registered?

1 0

Re: [alsa-devel] ASoC - Output widgets
by Mark Brown 26 Feb '08

26 Feb '08

On Mon, Feb 25, 2008 at 10:39:15AM +0100, Alexandre BOUIN wrote: > - 1 SND_SOC_DAPM_MIXER is connected to 2 SND_SOC_DAPM_PGA with power > control. > - each PGA is connected to an SND_SOC_DAPM_OUTPUT > - according to tosa example : > - first OUTPUT is connected to a SND_SOC_DAPM_HP defined as endpoint > - second OUTPUT is connected to a SND_SOC_DAPM_SPK defined as endpoint > this SPK is set disconnected in my tosa_ac97_init -like function Could you please post dmesg output with DAPM_DEBUG turned on which shows this happening?

2 1

Re: [alsa-devel] [Alsa-devel] Questions about sound/isa/sb/sb8_main.c
by Clemens Ladisch 26 Feb '08

26 Feb '08

Rask Ingemann Lambertsen wrote: > I'm looking at sound/isa/sb/sb8_main.c from linux 2.6.20. In > snd_sb8_capture_prepare(), a line reads: > > if (chip->capture_format != SB_DSP_OUTPUT) { > > Shouldn't this be SB_DSP_INPUT instead? Yes. Now fixed in the ALSA tree. Thanks! Clemens

1 0

[alsa-devel] POLLIN and POLLOUT event in pcm io plugins
by Pharaoh . 26 Feb '08

26 Feb '08

Hi, The structure snd_pcm_ioplug has following members: int poll_fd; /**< poll file descriptor */ unsigned int poll_events; /**< poll events */ and the associated events are POLLIN and POLLOUT, I suppose. I am unable to understand how these fields are getting used. There are many other plugins which dont use this. What is the significance of these fields? -pharaoh.

1 0

[alsa-devel] Fwd: HW decoding abstracted in ALSA
by Harsha priya gupta 25 Feb '08

25 Feb '08

Hi, Thanks for your immediate reply. My hardware supports MP3 decoding in HW (in addition to few others). I am looking to write a driver such that when an MP3 file is played, the file is decoded using the HW decoder and played. Is there a possibility in current ALSA framework to do so? Thanks, Harsha. On Mon, Feb 25, 2008 at 5:33 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > At Mon, 25 Feb 2008 12:27:00 +0530, > Harsha priya gupta wrote: > > > > Hi, > > > > I am new to ALSA and audio stack in Linux. I have a sound card that can > do > > HW decoding as well. I am looking at writing an ALSA driver such that > > whatever may be the player or MMF above, it should use the HW decoder > and > > not the inherit SW decoder that is available with the player. > > > > Can someone help me with some pointers or existing like-drivers? > > Which format is in mind? In theoery, you can implement the h/w > decoder on the ALSA framework, but there are some restrictions: > > - ALSA PCM assumes the constant bitrate > - The format bit must be defined > - The specific app recognizes and supports that format > > In the case of AC3 or DTS, it's embedded in SPDIF frames so the PCM > core stuff doesn't take care of the above. But, in the case of native > (non-PCM) formats, the support can be difficult as is. > > > Takashi > -- -Harsha -- -Harsha

1 0

[alsa-devel] Patch for alsa-info.sh - AC97 including regs
by Travis Place 25 Feb '08

25 Feb '08

Ok, ive added the +regs file aswell, but decided to store its output in a seperate tmp file (before being added to the complete output). This way, we can change how its output if we'd like, with less stuffing around (and all tmp files are cleaned up after each run, anyway). -- Happiness is like peeing your pants. Everyone can see it, but only you can feel its warmth

2 2

Re: [alsa-devel] hdsp rpm support
by kgrill＠chello.at 25 Feb '08

25 Feb '08

I started to work on this about a year ago, but had to stop because my son took the card to Istanbul where he spent a year studying. I'll get back to it in the next days, and depending on how much has changed in the meantime I may get something ready by the end of January. regards kg

3 4

[alsa-devel] Patch for alsa-info.sh
by Travis Place 25 Feb '08

25 Feb '08

Sorry for the frequent patch interval.. I think this will do for a while.. Adds AC97 codec output if an AC97 card is in the system. -- Happiness is like peeing your pants. Everyone can see it, but only you can feel its warmth

2 1

[alsa-devel] How does ALSA detect underrun in OSS emulation?
by Timur Tabi 25 Feb '08

25 Feb '08

Can someone explain to me the exact method that ALSA uses to detect underrun with OSS emulation? I have a driver that reports underrun on almost every period when I use OSS emulation and I'm playing with a non-supported sample rate. So I'm assuming that maybe my hardware is playing the audio too fast or too slow, and the driver is returning periods before ALSA expects them. What I don't understand is: how does ALSA know that a period was finished too early. Does it use a timer, or is it purely application driven? -- Timur Tabi Linux kernel developer at Freescale

2 3