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

Re: [alsa-devel] noise and consume pcm faster
by Takashi Iwai 05 Sep '08

05 Sep '08

At Fri, 5 Sep 2008 14:34:51 +0800, Nie Jun wrote: > > I can not figure out the reason of noise and faster consumption from these > different. Do you have any idea about these different? Or any other data may > contain clue? So, do you mean that the problem persists even if you use the exactly same period_size and buffer_size as OSS (i.e. 256 and 5120)? Takashi

1 0

[alsa-devel] Playing silence instead of pausing during underrun
by Timur Tabi 05 Sep '08

05 Sep '08

If I understand it correctly, when ALSA detects an underrun during playback, it throttles the driver by sending pause and resume commands. It turns out that our hardware doesn't really like this. We're looking at various solutions, but one proposal would be to keep the hardware running during a pause, but just have it play silence instead. That is, ALSA keeps feeding silence data during an underrun recovery. Is there an easy way to do this in ALSA? Is there another driver that does this? -- Timur Tabi Linux kernel developer at Freescale

3 3

Re: [alsa-devel] noise and consume pcm faster
by Nie Jun 05 Sep '08

05 Sep '08

Thank Takashi for your advice. I check /proc/asound/card0/pcm0p/sub0/* files, buffer_sizes of both ALSA and OSS have integer period_size. Maybe other setting causes this issue, but I can not find it. Would you guys please help have a look at these file? Thank you very much! =========== ALSA hw_params =========== access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 480 buffer_size: 9600 ----------------- OSS hw_params --------------------- access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 256 buffer_size: 5120 OSS format: S16_LE OSS channels: 2 OSS rate: 48000 OSS period bytes: 1024 OSS periods: 20 OSS period frames: 256 =========== ALSA sw_params =========== tstamp_mode: NONE period_step: 1 avail_min: 480 start_threshold: 9600 stop_threshold: 9600 silence_threshold: 0 silence_size: 0 boundary: 1258291200 ----------------- OSS sw_params --------------------- tstamp_mode: NONE period_step: 1 avail_min: 1 start_threshold: 1 stop_threshold: 5120 silence_threshold: 272 silence_size: 272 boundary: 1342177280 =========== ALSA status ========== state: RUNNING trigger_time: 946744218.914947510 tstamp : 946744304.440704346 delay : 8924 avail : 676 avail_max : 1940 ----- hw_ptr : 4105180 appl_ptr : 4114104 ---------------------- OSS status -------------------------- state: RUNNING trigger_time: 946744382.661376953 tstamp : 946744410.868988037 delay : 4908 avail : 212 avail_max : 4876 ----- hw_ptr : 1353952 appl_ptr : 1358860 ============= ALSA OSS has same info ----------------------------- card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: I2S HiFi I2S HiFi-PCM-0 name: subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0 2008/9/3 Takashi Iwai <tiwai(a)suse.de>:- 显示引用文字 -

2 1

Re: [alsa-devel] are freebob firewire cards likely to be supported by alsa in the future?
by Jonathan Woithe 05 Sep '08

05 Sep '08

Hi Andy > Just wondering if there are any plans to develop alsa support for > firewire freebob cards like the M-Audio firewire solo (which I have). I > have this working fine under jackd using the freebob driver, but as far > as I know there isn't an alsa driver for it. I assume that since there > is already open source code to drive the chip, it should be possible to > write an alsa driver? Yes, it would be possible. However, doing so would require that almost everything freebob/ffado currently does (which is a lot) would have to be ported and/or reimplemented. This doesn't seem like the best use of anyone's time. Instead, there are plans to write an alsa driver interface to libffado and some preliminary work has been done, but there's no ETA on this at present. Currently our (ffado's) focus is on getting things working well under JACK because users of firewire devices will also tend to be JACK users due to the nature of the firewire devices and the kind of work one normally does with them. > This isn't an urgent thing for me - for the moment I'm quite happy to use > my onboard card for playing music / movies etc, and keep the firewire card > for recording music etc, but it might be useful sometimes to have an alsa > driver for this card as well. Many media players are capable of connecting to JACK. xine, ecasound and mplayer are a few which come to mind off the top of my head. If your chosen applications don't do JACK, then you might have some success with oss2jack assuming your applications can use OSS devices (I haven't personally tried it so I don't know how well it works). There might even be an equivalent "alsa2jack" bridge but I haven't seen it if there is. Obviously your best bet would be to find media players which support JACK natively. Regards jonathan

1 0

[alsa-devel] alsa-lib, dmix, and snd_pcm_open_conf function
by Simon Tremblay 05 Sep '08

05 Sep '08

Hi, I have a problem using dmix on my embedded system (manual installation of alsa-lib 1.0.15) When I play a sound with aplay, it works well. When I try -D dmix or -D plug:dmix parameter, it doesn't work. The output is: aplay: main:547: audio open error: Operation not permitted I located my problem in alsa-lib, around line 2154 of alsa-lib/src/pcm/pcm.c: err = snd_pcm_open_conf(pcmp, name, root, pcm_conf, stream, mode); (in snd_pcm_open_noupdate function) err result is -1 when it's used with dmix... I don't know how works alsa-lib. I suppose snd_pcm_open_conf has something related with configuration files... Since I have all default configuration files... Maybe I must tweak some to be able to use dmix...

2 3

[alsa-devel] Using GDB for ALSA How to?
by William Estrada 05 Sep '08

05 Sep '08

Hi group, I am trying to use GDB with my ALSA program. I wish to display (print) a handle for an snd_pcm_t pointer. I am getting the following error: > (gdb) p Device > $9 = (snd_pcm_t *) 0x92be458 > (gdb) p *Device > $10 = <incomplete type> How do I display the snd_pcm_t structure? Thanks for your time. -- William Estrada MrUmunhum(a)popdial.com Mt-Umunhum-Wireless.net ( http://Mt-Umunhum-Wireless.net ) Ymessenger: MrUmunhum

2 5

[alsa-devel] are freebob firewire cards likely to be supported by alsa in the future?
by andy baxter 05 Sep '08

05 Sep '08

Hello, Just wondering if there are any plans to develop alsa support for firewire freebob cards like the M-Audio firewire solo (which I have). I have this working fine under jackd using the freebob driver, but as far as I know there isn't an alsa driver for it. I assume that since there is already open source code to drive the chip, it should be possible to write an alsa driver? This isn't an urgent thing for me - for the moment I'm quite happy to use my onboard card for playing music / movies etc, and keep the firewire card for recording music etc, but it might be useful sometimes to have an alsa driver for this card as well. andy

1 0

[alsa-devel] [ANNOUNCE] Git User's Survey 2008
by Jakub Narebski 04 Sep '08

04 Sep '08

Hi all, We would like to ask you a few questions about your use of the Git version control system. This survey is mainly to understand who is using Git, how and why. The results will be published on the Git Wiki http://git.or.cz/gitwiki/GitSurvey2008 and discussed on the git mailing list. The survey would be open from 1 September till 10 October. Please devote a bit of your time to fill this simple questionnaire; it will help a lot the Git community to understand your needs, what you like of Git, and of course what you don't like of it. The survey can be found here: http://www.survs.com/survey?id=M3PIVU72&channel=2WXE4BVTW8 http://tinyurl.com/GitSurvey2008 -- Git Development Community

1 0

Re: [alsa-devel] snd-soc-cs4270: Convert to a new-style i2c driver (work in progress)
by Jean Delvare 04 Sep '08

04 Sep '08

Hi Timur, On Sun, 31 Aug 2008 11:28:08 -0500, Timur Tabi wrote: > On Sun, Aug 31, 2008 at 9:18 AM, Jean Delvare <khali(a)linux-fr.org> wrote: > > Hi Tibur, > > It's "Timur" Oops, apparently I mixed your first name and last name. Sorry about that. > > I am in the process of converting your cs4270 codec driver from the > > legacy i2c model to the new (standard) one. > > It has already been converted. > > http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=0d… Ah, excellent. One less thing for me to do :) Thanks! Two comments about your patch: * Your driver now lacks a remove method. Unless I miss something, if the snd-soc-cs4270 driver is unloaded, you will leave dangling resources behind (codec->reg_cache in particular.) * I2C_DRIVERID_CS4270 must be removed from i2c-id.h. > I don't know why this commit hasn't been pushed upstream, though. As I understand it, without that patch the mpc8610_hpcd doesn't work, as the I2C address of the sound codec will be made busy by the platform code and thus the snd-soc-cs4270 driver won't be able to attach to it. If I am correct then I suggest that you ask Takashi to push the patch to Linus now to fix that. > > This is work in progress. > > The patch below converts the cs4270 driver itself. However we also need > > to convert its users. As far as I can see there's only one user at this > > point: mpc8610_hpcd. > > That's correct. I've never seen any interest in the CS4270 outside of > Freescale. > > > The problem is that this driver doesn't look like the other codec > > drivers I have already converted. So, we need to add code to > > instantiate the cs4270 i2c device, but I don't know where this should > > happen. Given that the mpc8610_hpcd is apparently based on Open > > Firmware, I guess that the i2c device should be instantiated directly > > by the platform code. I see that the device is declared in > > mpc8610_hpcd.dts, so maybe it's already done and my patch should work > > already? What do you think? > > I think you need to use the right git repository for your development. :-) Very good point indeed. I'll make sure to check Takashi's sound-2.6 tree before attempting to convert any other SoC codec driver. Do you know off the top of your head if other drivers have already been converted? Thanks, -- Jean Delvare

4 9

[alsa-devel] Pull request for alsa-plugins
by Lennart Poettering 04 Sep '08

04 Sep '08

Takashi, Jaroslav, please pull and merge a series of 26 patches for alsa-plugins' PulseAudio driver which I prepared in this repository of mine: git://git.0pointer.de/alsa-plugins.git gitweb is here: http://git.0pointer.de/?p=alsa-plugins.git There are quite a few bug fixes and feature enhancements among those patches. It also includes some clean-ups in the coding style. i.e. previously the indenting of the PA driver was pure chaos, every single patch seemed to introduce a new indentation width. The first patch in this series simply reindents the driver to Linux style. All other patches are on top of that one. Here's the shortlog: Lennart Poettering (26): Reindent to Linux kernel style Add Emacs-style /*-*- linux-c -*-*/ header comment Make pulse_new() a proper C function Don't modify the SIGPIPE handler Call pa_context_disconnect() explicitly use SNDERR instead of fprintf to print error messages Support S32 sample types Add trailing NUL character to snprintf output Get rid of pulse_poll_revents() Add more error checking Remove fix for bug 0003470 Rework hardware parameter selection A bag of minor clean ups for ctl_pulse.c Make pulse_ext_callback const Drop our own implementation of the poll() callbacks A bag of minor clean-ups for pulse.c Split out O_NONBLOCK setting into seperate function Save a byte of memory Adjust buffering metrics to match what PA internally uses Make sure we always have a sensible channel mapping Use PA_STREAM_EARLY_REQUESTS if available Use S32/FLOAT32 only where available in the PA libs Add const to our snd_pcm_ioplug_callback_t instances Don't implement our own poll handlers, we can use the default ones Remove our own poll handler implementation entirely A bag of clean-ups for pcm_ctl.c Those patches only touch the pulse/ subdir. The tree is freshly rebased against current alsa-plugins master. May I ask you to make me the "semi-official" maintainer of this driver? I.e. I'd like to be consulted (as in 'Signed-Off-by') before any patches for it are merged? If requested I can also mail this as series of 26 seperate patches. Thank you, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

3 3