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

[alsa-devel] Unable to bypass alsa plugins and write directly to hw:0, 0
by Pharaoh . 10 Sep '07

10 Sep '07

My sound card supports hardware upsampling i.e. I do not need to use the software up sampling done by plugins like dmix etc. For testing hw up sampling, I tried to play an 8K sample rate wav file as follows, but some how it is being upsampled, I think I am missing something. # aplay -Dhw:0,0 8k.wav -v Playing WAVE '8k.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo Warning: rate is not accurate (requested = 8000Hz, got = 44100Hz) please, try the plug plugin Hardware PCM card 0 'OMAP850 EAC' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22052 period_size : 5513 period_time : 125011 tick_time : 10000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 5513 xfer_align : 5513 start_threshold : 22052 stop_threshold : 22052 silence_threshold: 0 silence_size : 0 boundary : 1445199872 I have attached my alsa.conf. -pharaoh.

2 1

[alsa-devel] Fwd: Re: RME HDSPe Info/Question
by ricman 10 Sep '07

10 Sep '07

Posting reply from kind responder providing additional info... --- Colin Stewart Campbell <colin.campbell(a)comhem.se> wrote: > From: Colin Stewart Campbell <colin.campbell(a)comhem.se> > Subject: Re: [alsa-devel] RME HDSPe Info/Question > Date: Mon, 10 Sep 2007 14:23:28 +0200 > To: ricman <the_ricman(a)yahoo.com> > > Well, except for that the new PCIe cards do all the floating-point > conversion in hardware and present 32-bit float instead of 32-bit > integer data on the bus. > If the alsa driver handles this, then ok. If not then you'll have to > > wait. Those running OSX on Intel machines with PCI slots already got > > hit by this format issue. > > Colin > ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

2 1

[alsa-devel] [PATCH] ad1848: replace HZ calculus with msecs_to_jiffies()
by Rene Herman 10 Sep '07

10 Sep '07

Hi Takashi. If I'm not mistaken, any (new) use of HZ these days is considered a bug so while I'm there... Signed-off-by: Rene Herman <rene.herman(a)gmail.com> Rene. diff --git a/sound/isa/ad1848/ad1848_lib.c b/sound/isa/ad1848/ad1848_lib.c index dcd4435..161da11 100644 --- a/sound/isa/ad1848/ad1848_lib.c +++ b/sound/isa/ad1848/ad1848_lib.c @@ -237,7 +237,7 @@ static void snd_ad1848_mce_down(struct snd_ad1848 *chip) #if 0 printk("(2) jiffies = %li\n", jiffies); #endif - time = HZ / 4; + time = msecs_to_jiffies(250); while (snd_ad1848_in(chip, AD1848_TEST_INIT) & AD1848_CALIB_IN_PROGRESS) { spin_unlock_irqrestore(&chip->reg_lock, flags); if (time <= 0) { @@ -250,7 +250,7 @@ static void snd_ad1848_mce_down(struct snd_ad1848 *chip) #if 0 printk("(3) jiffies = %li\n", jiffies); #endif - time = HZ / 10; + time = msecs_to_jiffies(100); while (inb(AD1848P(chip, REGSEL)) & AD1848_INIT) { spin_unlock_irqrestore(&chip->reg_lock, flags); if (time <= 0) {

1 0

[alsa-devel] [PATCH] ad1848 and cs4231 busy loop replacement
by Krzysztof Helt 10 Sep '07

10 Sep '07

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> This patch replaces busy loop with msleep and removes incorrect debug message. Signed-off-by: Krzysztof Helt <krzysztof.h1(a)wp.pl> --- This should fix Rene's problem with the timeout message he got in his new Aztech driver. The problem is that the driver wait for busy bit to go high but it may not happen if the auto-calibration is not set. The result is incorrect debug message (that timeout happened). It is also possible (in theory) to get this message in the ad1848-lib on a slow CPU. The patch just wait a period around the period needed for the auto-calibration. If there is no auto-calibration set, the driver just loses few miliseconds. This may happen only during driver start as both drivers set auto-calibration. If the auto-calibration is set we give CPU more time to do something else then move to next waiting loop (for the auto-calibration bit to get cleared). The msleep delay is calculated as rounded down time of waiting number of cycles (from ad1848k and cs4231a specs) with the highest frequency (48kHz). Rene, please test this patch on the cs4231 codec. diff -urp linux-2.6.22/sound/isa/ad1848/ad1848_lib.c linux-2.6.23/sound/isa/ad1848/ad1848_lib.c --- linux-2.6.22/sound/isa/ad1848/ad1848_lib.c 2007-09-08 23:53:42.958067597 +0200 +++ linux-2.6.23/sound/isa/ad1848/ad1848_lib.c 2007-09-08 23:57:31.255077502 +0200 @@ -229,17 +229,12 @@ static void snd_ad1848_mce_down(struct s spin_unlock_irqrestore(&chip->reg_lock, flags); return; } + /* calibration process */ + msleep(7); + + snd_printd("(2) jiffies = %li\n", jiffies); - for (timeout = 500; timeout > 0 && (snd_ad1848_in(chip, AD1848_TEST_INIT) & AD1848_CALIB_IN_PROGRESS) == 0; timeout--); - if ((snd_ad1848_in(chip, AD1848_TEST_INIT) & AD1848_CALIB_IN_PROGRESS) == 0) { - snd_printd("mce_down - auto calibration time out (1)\n"); - spin_unlock_irqrestore(&chip->reg_lock, flags); - return; - } -#if 0 - printk("(2) timeout = %i, jiffies = %li\n", timeout, jiffies); -#endif time = HZ / 4; while (snd_ad1848_in(chip, AD1848_TEST_INIT) & AD1848_CALIB_IN_PROGRESS) { spin_unlock_irqrestore(&chip->reg_lock, flags); diff -urp linux-2.6.22/sound/isa/cs423x/cs4231_lib.c linux-2.6.23/sound/isa/cs423x/cs4231_lib.c --- linux-2.6.22/sound/isa/cs423x/cs4231_lib.c 2007-09-08 23:53:29.005272473 +0200 +++ linux-2.6.23/sound/isa/cs423x/cs4231_lib.c 2007-09-08 23:56:52.824887490 +0200 @@ -334,19 +334,12 @@ void snd_cs4231_mce_down(struct snd_cs42 !(chip->hardware & (CS4231_HW_CS4231_MASK | CS4231_HW_CS4232_MASK))) { return; } - snd_cs4231_busy_wait(chip); /* calibration process */ + msleep(2); + + snd_printd("(2) jiffies = %li\n", jiffies); - for (timeout = 500; timeout > 0 && (snd_cs4231_in(chip, CS4231_TEST_INIT) & CS4231_CALIB_IN_PROGRESS) == 0; timeout--) - udelay(10); - if ((snd_cs4231_in(chip, CS4231_TEST_INIT) & CS4231_CALIB_IN_PROGRESS) == 0) { - snd_printd("cs4231_mce_down - auto calibration time out (1)\n"); - return; - } -#if 0 - printk("(2) timeout = %i, jiffies = %li\n", timeout, jiffies); -#endif /* in 10 ms increments, check condition, up to 250 ms */ timeout = 25; while (snd_cs4231_in(chip, CS4231_TEST_INIT) & CS4231_CALIB_IN_PROGRESS) {

2 9

[alsa-devel] alsaseq 0.1 Python module
by Patricio Paez 10 Sep '07

10 Sep '07

Hello all, This was posted in the Python announce list, but it could be of interest here: "The first version of alsaseq, bindings to the ALSA sequencer has been released. alsaseq is a Python module that allows to interact with ALSA sequencer clients. It can create an ALSA client, connect to other clients, send and receive ALSA events immediately or at a scheduled time using a sequencer queue. It provides a subset of the ALSA sequencer capabilities in a simplified model. It is implemented in C language and licensed under the Gnu GPL license version 2 or later. Home http://pp.com.mx/python/alsaseq Download http://pp.com.mx/python/alsaseq/alsaseq-0.1.tar.gz " It is an early and ongoing project, suggestions and comments are welcome. Regards, Patricio Páez <pp at pp.com.mx> Original post: http://mail.python.org/pipermail/python-announce-list/2007-September/006102…

1 0

[alsa-devel] Pausing an audio stream during playback using mixer control interface
by Pharaoh . 10 Sep '07

10 Sep '07

Hi I want to provide a mixer control interface which will pause the playback and resume it as needed. I tried to disable DMA while pausing and enable it while releasing, but this doesn't stop alsa upper layers from inquiring the buffer position and since DMA is not on, it gives a pcm write error, which is quite obvious. I know that, SNDRV_PCM_TRIGGER_PAUSE_PUSH can be used in trigger callback to pause the stream, but I want to give a mixer interface to do the same. As per my understanding this is not possible keeping in mind the current framework, can anyone think of any work around? -pharaoh.

2 1

[alsa-devel] RME HDSPe Info/Question
by ricman 10 Sep '07

10 Sep '07

Howdy! I would like to share a piece of information which I am hoping will be helpful to the ALSA development community. This information is regarding the RME HDSP Multiface/Digiface family of products. We know from http://www.alsa-project.org/main/index.php/Matrix:Vendor-RME and http://www.alsa-project.org/main/index.php/Matrix:Module-hdsp that we have a PCI driver for Linux thanks to Paul Davis, Marcus Andersson, Thomas Charbonnel (and probably others). However, RME recently came out with a new PCI Express (PCI-E) interface for these products. Here is where is gets interesting: I've been trying to ascertain whether I should purchase the PCI-E HDSPe card for my Linux box. I prayed to the RME gods on their forum and none other than Matthias Carstens of RME responded that "The PCIe cards are fully downward compatible, so can be used even with the oldest Windows drivers. So I expect Linux to work with them too." (http://www.rme-audio.de/forum/viewtopic.php?id=1031) Is it possible that he is right? Will the old PCI Linux driver work just the same (or better) with the newer PCI-E card? For some reason I just naturally thought the PCI-E card would need its own special driver. Or is the only way to know to just buy and see if it works? That seem like an expensive way to find out... Thanks! ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/

2 1

[alsa-devel] period_size and relation to number of samples
by Markus Korber 10 Sep '07

10 Sep '07

Hello, one question: If my driver announces the setting below[1], how many samples must an application provide in a single snd_pcm_writei() or snd_pcm_mmap_writei() call? Shouldn't it always send 8192 bytes or 2048 left and right samples (4096 in total) or is it free to send more or less? Logging data in my chip_playback_copy() function shows the following (S16_LE, RW_INTERLEAVED): ,----[ mplayer, aplay: ] | chip_playback_copy (0 -> src: 0xffce1000, #bytes: 0x4000) | chip_playback_copy (1 -> src: 0xffce1000, #bytes: 0x2000) | chip_playback_copy (1 -> src: 0xffce1000, #bytes: 0x2000) `---- ,----[ alsaplayer: ] | chip_playback_copy (0 -> src: 0xffce1000, #bytes: 0x2000) | chip_playback_copy (0 -> src: 0xffce3000, #bytes: 0x2000) | chip_playback_copy (0 -> src: 0xffce3000, #bytes: 0x2000) | [...] `---- Thus mplayer and aplay provide 16384 bytes (4096 l/r samples) in the first call and 8192 bytes (2048 l/r samples) for all subsequent calls. However, alsaplayer provides 8192 bytes (2048 l/r samples) for all calls. Now, what is an application allowed to send and what not? For example, could an application only send 1024 l/r samples and is the driver responsible for buffering the data? Or must it obey the announced period_size and *always* provide 2048 l/r samples? Thanks. ,----[ 1 ] | stream : PLAYBACK | access : RW_INTERLEAVED | format : S16_LE | subformat : STD | channels : 2 | rate : 44100 | exact rate : 44100 (44100/1) | msbits : 16 | buffer_size : 4096 | period_size : 2048 | period_time : 46439 | tick_time : 10000 | tstamp_mode : NONE | period_step : 1 | sleep_min : 0 | avail_min : 2048 | xfer_align : 1 | start_threshold : 2048 | stop_threshold : 4096 | silence_threshold: 0 | silence_size : 0 | boundary : 1073741824 | start_mode: DATA | xrun_mode: STOP | tstamp_mode: NONE | period_step: 1 | sleep_min: 0 | avail_min: 2048 | xfer_align: 1 | silence_threshold: 0 | silence_size: 0 | boundary: 1073741824 `---- Regards, Markus Korber

2 4

Re: [alsa-devel] [Alsa-user] Disable MIDI port creation with ICE1724
by Rene Herman 10 Sep '07

10 Sep '07

On 09/08/2007 03:32 AM, James Roberts wrote: > I need to disable the creation of the ICEnsemble ICE1724 midi device on > my system. I am using a off-brand card (see below) and accessing the > midi device crashes the system hard. > > I have explored udev rules, kernel opts, etc ad nauseum to do this. > > To be clear I do not want to use the midi capabilities of the sound card > at all, but want to keep the sound capabilities. > > lspci: > 00:09.0 Multimedia audio controller: VIA Technologies Inc. VT1720/24 > [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01) > > amidi -l: > Dir Device Name > IO hw:0,0 ICEnsemble ICE1724 MIDI <- this must be gone forever! > IO hw:1,0,0 BCF2000 MIDI 1 > IO hw:1,0,1 BCF2000 MIDI 2 > O hw:1,0,2 BCF2000 MIDI 3 > > > It appears to get assigned to midiC0D0 > > Am I better off going the udev route and trying to somehow assign a null > value somewhere or is there a way to prevent alsa from creating it? > > Maybe an alias? Sounds like this may warrent a module parameter. Trivial, untested version below, but this needs a module maintainer to decide if there may be better ways to discriminate. Crossposted to alsa-devel... (against 2.6.22.x). Rene. diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c index ee620de..1d64dcc 100644 --- a/sound/pci/ice1712/ice1724.c +++ b/sound/pci/ice1712/ice1724.c @@ -75,6 +75,7 @@ static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-MAX */ static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; /* ID for this card */ static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP; /* Enable this card */ static char *model[SNDRV_CARDS]; +static int no_mpu401[SNDRV_CARDS]; module_param_array(index, int, NULL, 0444); MODULE_PARM_DESC(index, "Index value for ICE1724 soundcard."); @@ -84,6 +85,8 @@ module_param_array(enable, bool, NULL, 0444); MODULE_PARM_DESC(enable, "Enable ICE1724 soundcard."); module_param_array(model, charp, NULL, 0444); MODULE_PARM_DESC(model, "Use the given board model."); +module_param_array(no_mpu401, int, NULL, 0444); +MODULE_PARM_DESC(no_mpu401, "Mmf mmmff mmfmf mff mmfmmff."); /* Both VT1720 and VT1724 have the same PCI IDs */ @@ -2398,7 +2401,7 @@ static int __devinit snd_vt1724_probe(struct pci_dev *pci, } } - if (! c->no_mpu401) { + if (! c->no_mpu401 && ! no_mpu401[dev]) { if (ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_MPU401) { if ((err = snd_mpu401_uart_new(card, 0, MPU401_HW_ICE1712, ICEREG1724(ice, MPU_CTRL),

2 1

[alsa-devel] alsaplayer configure says Build alsa 0.9.x output plugin: no
by Timur Tabi 10 Sep '07

10 Sep '07

I have a working ALSA driver on my system. I downloaded the latest alsaplayer and when I ran ./configure, it says this: Build alsa 0.9.x output plugin: no I looked at the source code for configure, and I found this: if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | $EGREP "AP_maGiC_VALUE" >/dev/null 2>&1; then have_alsa_final=yes But I don't understand it. What do I need to have to get alsaplayer to build ALSA output support? -- Timur Tabi Linux Kernel Developer @ Freescale

3 3