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

Re: [alsa-devel] [PATCH] es1968: fix jitter on some maestro cards
by Rene Herman 14 Apr '08

14 Apr '08

On 30-03-08 00:49, Andreas Mueller wrote: > This patch suppresses jitter on several Maestro cards in stereo mode > (ALSA of course). > > The patch is also incorporated in the *BSD drivers where I "ported" it from. > I am barely used to driver-development so please take a look (esp. the channel > parameters), nevertheless it completely works for me. > > Without this patch most of the stereo audio gets out of sync and really > distorted (oss-emulation with mplayer at 48000khz worked somehow). > > CCed to those listed in the .c file. Added the alsa-devel list (and re-attached the patch). My TerraTec DMX (ESS Canyon3D, ES1970MS-3D) doesn't need this but doesn't seem to suffer from it either. Otherwise no idea about this. Rene. --- sound/pci/es1968.c.old 2008-03-29 19:17:16.771116317 +0100 +++ sound/pci/es1968.c 2008-03-30 00:14:35.363057160 +0100 @@ -1816,7 +1816,24 @@ return 0; } +/* + * suppress jitter on some maestros when playing stereo + */ +static void snd_es1968_suppress_jitter(struct es1968 *chip, struct esschan *es) +{ + unsigned int cp1; + unsigned int cp2; + unsigned int diff; + cp1 = __apu_get_register(chip, 0, 5); + cp2 = __apu_get_register(chip, 1, 5); + diff = (cp1 > cp2 ? cp1 - cp2 : cp2 - cp1); + + if (diff > 1) { + __maestro_write(chip, IDR0_DATA_PORT, cp1); + } +} + /* * update pointer */ @@ -1937,8 +1954,11 @@ struct esschan *es; spin_lock(&chip->substream_lock); list_for_each_entry(es, &chip->substream_list, list) { - if (es->running) + if (es->running) { snd_es1968_update_pcm(chip, es); + if (es->fmt & ESS_FMT_STEREO) + snd_es1968_suppress_jitter(chip, es); + } } spin_unlock(&chip->substream_lock); if (chip->in_measurement) {

2 2

[alsa-devel] [PATCH]PCI quirk for laptop LG which use CMI9880
by Jiang zhe 14 Apr '08

14 Apr '08

Hi, Please refer to [0003874] on the alsa mantis. This patch added the pci quirk. Thanks! Signed-off-by: Jiang zhe <zhe.jiang(a)intel.com>

2 1

[alsa-devel] [PATCH] soc - Include register in DAPM debug output
by Mark Brown 14 Apr '08

14 Apr '08

When logging register changes in DAPM debug output include the register number. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-dapm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index abac684..e0637d8 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -226,7 +226,7 @@ static int dapm_update_bits(struct snd_soc_dapm_widget *widget) snd_soc_write(codec, widget->reg, new); pop_wait(POP_TIME); } - dbg("reg old %x new %x change %d\n", old, new, change); + dbg("reg %x old %x new %x change %d\n", widget->reg, old, new, change); return change; } -- 1.5.4.4

2 1

[alsa-devel] [PATCH]PCI quirk for MSI laptop
by Jiang zhe 14 Apr '08

14 Apr '08

Hi, Please refer to [0003848] on the alsa mantis. This patch adds the pci quirk and Mic-Int controller. Thanks! Signed-off-by: Jiang zhe <zhe.jiang(a)intel.com>

2 1

[alsa-devel] Loop sequencer
by Guillaume Dupré 06 Apr '08

06 Apr '08

Hello I try to program a loop midi sequencer with libasound . For the moment, I have this : #include <alsa/asoundlib.h> #include <unistd.h> using namespace std; int main() { int aa; snd_seq_t* seq; int port,port2, queue; snd_seq_queue_tempo_t* tempo; snd_seq_event_t ev; snd_seq_open(&seq, "default", SND_SEQ_OPEN_DUPLEX, 0); snd_seq_set_client_name(seq, "monprog"); port = snd_seq_create_simple_port(seq, "port1",SND_SEQ_PORT_CAP_READ | SND_SEQ_PORT_CAP_SUBS_READ,SND_SEQ_PORT_TYPE_APPLICATION); queue = snd_seq_alloc_queue(seq); //TEMPO snd_seq_queue_tempo_alloca(&tempo); snd_seq_queue_tempo_set_tempo(tempo, 60000000 / 120); snd_seq_queue_tempo_set_ppq(tempo, 4); snd_seq_set_queue_tempo(seq, queue, tempo); snd_seq_connect_to(seq, port, 130, 0); snd_seq_start_queue(seq, queue, NULL); // write 2 notes snd_seq_ev_clear(&ev); snd_seq_ev_set_subs(&ev); snd_seq_ev_set_source(&ev, port); snd_seq_ev_schedule_tick(&ev, queue, 0, 0); snd_seq_ev_set_note(&ev, 0, 60, 127, 3); snd_seq_event_output(seq, &ev); ev.time.tick = 4; ev.data.note.note = 67; snd_seq_event_output(seq, &ev); snd_seq_drain_output(seq); sleep(4) ; return 0; } It works, no problem . But now, I want to do a loop with my two notes . I searched on the Internet but I didn't find . Thanks Guillaume Dupré

2 1

[alsa-devel] Altec Lansing FX5051 mixer
by Jeremy Nickurak 04 Apr '08

04 Apr '08

I recently purchased an Altec Lansing USB Surround speaker set. (It's a set of 5.1 speakers, with a built-in USB sound card). I've got about a week before the return policy expires and I'd have to return it. The mixer doesn't work at all w/linux kernel 2.6.22, everything is locked at 100% volume, which is pretty unhelpful, as it's the only way to adjust the volume. (no analog controls). Also, the digital control panel locks up when the speakers power up, further preventing any access to the volume controls. The device works out-of-the-box without any drivers under XP, so I have to so-far assume that alsa's usb-audio is missing something. Any thoughts as to what could be wrong? I'm more than happy to prod the device and submit any information I can extract about it, or even potentially opening the device up for remote access if a reputable developer is interested in examining it. -- Jeremy Nickurak -= Email/Jabber: atrus(a)rifetech.com =-

3 4

Re: [alsa-devel] PXA2xx/3xx AC97 Driver(s)
by Mark Brown 02 Apr '08

02 Apr '08

On Mon, Mar 24, 2008 at 12:38:00PM +0000, Oliver Ford wrote: > Is there any work currently under way on an AC97 driver for the PXA3xx? There is PXA3xx AC97 support present in the ASoC tree: git://opensource.wolfsonmicro.com/linux-2.6-asoc It's under the asoc-v2-dev branch at the minute and is probably only done for the ASoC AC97 driver, I'd need to check. The main reason it's only there is that it depends on the ARM architecture changes that you identified (which are also applied on the asoc-v2-dev branch) and it makes life easier to manage the cross-tree changes in only one tree. All the ARM architecture changes have been submitted and marked as applied in the patch system so should hopefully appear in Linus' kernel early in the 2.6.26 cycle. Once this has happened I will submit the AC97 driver PXA3xx support. > I want to get the touch screen working on my iPAQ 214, which uses the > PXA310. It's a WM97xx chip on the AC97 interface. I'm not really too I know that there are a number of users currently using the tree for that use case so the asoc-v2-dev branch should hopefully work for you. If you run into trouble please let me know. > include/asm-arm/arch-pxa/pxa3xx-regs.h). Does the pxa310 require > anything special like this or should just setting the cold-reset in > the AC97 GCR work? It also doesn't support the use of interrupts during reset operations, requiring another special case, but I think that's about it. > The Wolfson Microelectronics open-source page indicates that work is on > going with the 3xx driver but there doesn't seem to be anything more > than the pxa2xx driver in their source tree. Does anyone know how active > / close to producing anything this is? Like I say, it's there. The changes are fairly straightforward and should be easy to backport to whatever kernel you need - if you need help identifying what needs merging over please just ask. > More generally, I'm a little confused as to why there is both the > standard (sound/arm/pxa2xx-ac97.c) and SoC (sound/soc/pxa/pxa2xx-ac97) > driver. Is one of these obsolete now or are they both still in > development? If guessing, I'd say the SoC driver is now the one to use The SoC driver is generally preferable, though it requires a bit more work to use (since you have to write a platform driver to use it). Both are still maintained. SoC offers better power management and support for a wider range of board configurations, especially those that also have non-AC97 interfaces (such as the I2S interface on the WM97xx parts). > but am not sure. Compiling either gives the warning "'pxa_set_cken' is > deprecated". I suspect calling this won't work for the pxa310 since it's This is also fixed in the patches currently queued in the ARM tree - the drivers have been converted to use the clk_() API. > clocks are different, but given that I'm booting linux from windows > (which will leave the clock on) and don't particularly care about > suspend/resume, should not being able to switch it off be a problem? The cken calls should actually work fine.

2 3

[alsa-devel] snd-powermac
by Risto Suominen 02 Apr '08

02 Apr '08

I'm about to send the following to alsa-user mailing list: I've been trying to fix ALSA support for older PowerMacs. Anyone experiencing problems - like missing or inoperative or wrongly directed controls in alsamixer - could you, please, test my patch and write the results into this list or directly to me? If you are still with me, check first with lsmod that you are using snd-powermac: $ lsmod | grep ^snd.powermac snd_powermac 56576 0 $ Then you will need to install make, C-compiler and kernel headers corresponding to your running kernel, f.ex (Ubuntu Dapper 6.06.1): $ sudo aptitude install make gcc linux-headers-2.6.15-26-powerpc and fetch the ALSA driver source code and my patch: $ wget ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.16.tar.bz2 $ wget http://ristosu.wippiespace.com/pub/alsa-driver-1.0.16-p4.diff Unpack the source and apply the patch: $ tar xjf alsa-driver-1.0.16.tar.bz2 $ cd alsa-driver-1.0.16 $ patch -p0 < ../alsa-driver-1.0.16-p4.diff Finally configure: $ ./configure --disable-verbose-printk --with-kernel=/usr/src/linux-headers-2.6.15-26-powerpc --with-build=/usr/src/linux-headers-2.6.15-26-powerpc --with-moddir=/lib/modules/2.6.15-26-powerpc/updates/sound --with-isapnp=no --with-oss=yes --with-pcm-oss-plugins=yes --with-cards=powermac make and install: $ make $ sudo make install-modules To load the new modules without rebooting: $ sudo modprobe -r snd-powermac $ sudo modprobe -r snd-pcm-oss $ sudo modprobe snd-powermac Risto

1 3

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha
by rct＠frus.com 01 Apr '08

01 Apr '08

rct wrote: > Rene Herman wrote: > > Okay, and applying the attached just makes your sound completely dead in the > > water? > > (patch to remove es1888_init from a Miata build omitted) > > I'll try a build with the old OSS "sb" driver, and if that works ok, we > may be able to do away with es1888_init() on the Miata. Tyson -- I > think you have a Miata if I'm remembering correctly: can you confirm > these observations? Quick followup: OSS "sb" driver works fine without es1888_init(). -- ------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did rct(a)frus.com | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------

5 8

[alsa-devel] [Fwd: Re: Davinci ASoC support (patch)]
by lokowich 01 Apr '08

01 Apr '08

Forwarded from davinci-linux-open-source list: I've built this ASoC patch into my DaVinci git kernel (thanks for the SENSORS tip), and can use aplay and speaker-test, but no sound. Figured it may be a mixer/volume control issue, but the alsamixer is unable to open for a failed ioctl on USBDEVFS_IOCTL. Not sure why there is a USB dependency. Noted that there is no /sys/class/sound/mixer in my sysfs. Any ideas? Mark Bernard Blackham wrote: > Behme wrote: > >> While searching something different, I just found >> >> http://www.spinics.net/lists/alsa-devel/msg12535.html >> >> As I'm not subscribed to alsa-devel, I don't have the original post. >> Maybe any of the authors can post it do this list as well? >> >> The patch mainly applies to our git. I fixed two small rejects in >> Kconfig and Makefile as the patch is for newer kernel than our git. >> Untested patch against our git in attachment. Anybody likes to test? >> > > Well, I tried compiling it and it failed to build. It appears that it's > built on a set of patches for Davinci posted to LAK, including this > completely revamped EDMA support[1]: > > http://www.spinics.net/lists/arm-kernel/msg47450.html > > So I had to change a few definitions, import a few functions from the new > DMA support and managed to get it compiling and loading, but not yet working > (tried various sample rates and formats): > > root@davinci-dvevm:/tst$ aplay test.wav > Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo > ALSA lib pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not usable > aplay: set_params:878: Broken configuration for this PCM: no configurations > available > > root@davinci-dvevm:/tst$ arecord -r 48000 -f S16_LE > Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono > ALSA lib pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not usable > arecord: set_params:878: Broken configuration for this PCM: no > configurations available > > > And this is the extent of my knowledge of ALSA - I can continue digging, but > maybe somebody else will beat me to it =) It's looking promising though. > > Attached is the patch I have so far that applies against current git. This > is not for going upstream, but just for testing. Notes: > - Apply patch > - Enable SND_SOC, SND_DAVINCI_SOC, SND_DAVINCI_SOC_I2S, SND_DAVINCI_SOC_EVM > and SND_SOC_TLV320AIC3X. > - Make sure CONFIG_I2C_DAVINCI is enabled, but disable the > CONFIG_SENSORS_TLV320* options. > - Build. > - Load the snd-soc-evm module. > > Bernard. > > [1] These patches appear to have gone absolutely nowhere beyond that list. I > can't find them in any tree. But they are cleaner and more conforming to the > Linux Kernel style than what's currently in git. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source(a)linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >

4 8