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

Re: [alsa-devel] [Audacity-devel] distortion with alsa I/O - no distortion with oss emulation
by Simon Lewis 10 Apr '07

10 Apr '07

Dear Alsa developers Audacity seems to work perfectly with AOSS and Jack but not directly with ALSA on some linux PCs. Trying to use ALSA directly leads to severe distortion due to lack of sync with Alsa. (I hope that is the correct terminology.) I received this reply from the Audacity developers, what tools are available from ALSA to investigate this problem? How can I determine what the real "Alsa configuration" is that portaudio has used setting up communication with Alsa. Best Regards, Simon > Markus Meyer schrieb: > > > As for Simon's problems with "synchronisation", I'm not so sure that it > is a Portaudio issue, or a software issue at all. Software issues tend > to be of the "on/off" type, and Portaudio does work well with ALSA in > the general case. Apart from being a hardware issue (defective sound > card, main board or something) this could also well be a race condition > in the ALSA driver (kernel module) which is only triggered by certain > buffer sizes, order of driver requests etc. Because Audacity is > multi-threaded it certainly stresses the driver/kernel subsystem more > than just, say, "arecord", which just gets blocks from the driver and > writes it out to disk. > > > Markus > > >> Simon Lewis schrieb: >> >> The main issue is that on some linux machines, mine included, there is >> severe distortion when Audacity is used with ALSA drivers. >> >> You will be pleased to hear that I have found the root cause of the >> problem. It is nothing to do with the options with which Audacity is >> compiled. The root cause is that portaudio loses synchronisation with >> ALSA's data stream. >> >> I was able to verify this yesterday, as I could start Audacity with >> Jack, and through Jack set up a number of simulation conditions and >> monitor the results. >> >> With my standard Jack settings of 96kHz / 256 Frames per period / 2 >> periods per buffer (latency 5.33 msecs.), ALSA initialises with sample >> format 32bit little-endian, 2 periods for capture and 2 periods for >> playback. >> >> Under these conditions Audacity cannot synchronise with the data stream >> and severe distortion is the result. >> >> However, increasing the frames per period to 1024 (latency 21.3 msec) >> and Audacity (1.3.2 with resampling disabled) runs perfectly and I can >> record for a long time. (CPU load is 9.6%) >> >> Reducing the frames per period to 512 and the same version of Audacity >> starts OK but after a few seconds, sometimes longer losses sync with the >> data stream. >> >> The standard 1.3.2 version of Audacity with resampling enabled does not >> sync on start with 512 frames per period but runs OK with Jack set to >> 1024 frames per period. >> >> The 1.3.3 version of Audacity complied with libsamplerate without >> portmixer runs OK with 512 frames per period under jack. >> >> NONE of the Audacity versions will run directly with the ALSA drivers. >> The Version with resampling disabled often starts OK, but after 30 sec >> to a few minutes of recording sync is lost and naturally distortion is >> the result. >> >> The conclusion is that portaudio is very poor at syncing with the >> alsadata stream, something which Jack can do with very little buffering. >> >> >> Ciao, Simon

3 2

[alsa-devel] Correct use of ak4114.c?
by dustin＠seznam.cz 10 Apr '07

10 Apr '07

Hello, while working on support for AK4114 in Audiotrak MI/ODI/O card, I used corresponding code from revo.c (and similarly from juli.c), calling function snd_ak4114_create. However, this function does not initialize array ak4114->kctls[idx], leading to consequent kernel oops after the periodically called snd_ak4114_check_rate_and_errors, specifically in function snd_ctl_notify called by snd_ctl_notify(ak4114->card, SNDRV_CTL_EVENT_MASK_VALUE, &ak4114->kctls[0]->id) Temporarily I resolved the problem by commenting out the snd_ctl_notify calls. However, it seems author of ak4114.c intended to create the device with snd_ak4114_build instead which defines all the controls. I did not hit the problem until fixing the 4-wire communication in revo.c - that explaing why nobody had this problem with revo cards. I do not understand how the code can work in juli.c - perhaps I have overlooked something there. My question: Is the correct way to add null pointer checks before snd_ctl_notify calls only, or to use snd_ak4114_build insted of snd_ak4114_create? If using snd_ak4114_build, where do I get the parameters ply_substream and cap_substream? int snd_ak4114_build(struct ak4114 *ak4114, struct snd_pcm_substream *playback_substream, struct snd_pcm_substream *capture_substream); Thanks for any suggestions. Pavel.

3 21

[alsa-devel] seq: timing unstable on slow computer when busy
by Gerald Grabner 09 Apr '07

09 Apr '07

Hi there, I'm trying to use a simple (self written) sequencer application on an old laptop with a 350 MHz CPU. It works, but the timing of output events becomes unstable when my program is busy with things like scheduling events for the subsequent loop or an unmuted track. I'm wondering about the best approach to tackle this problem. Depending on how the priority of the kernel's event scheduling is related to the priority of an application, I could imagine some of the following measures: * Running my process with lower or higher priority * Using (priorized) threads for the event scheduling * Setting Linux kernel config options * Setting ALSA related options (driver or lib) * ... While playing midi, I'm scheduling an echo event a few ticks before the end of every sequence, upon which a function to schedule the events of the next sequence is called. What is the typical length of this scheduling span: Just one bar? Or longer? Many thanks in advance, Gerald BTW: My operation system is Gentoo's Linux 2.6.19 with alsa-driver 1.0.14_rc1.

2 1

[alsa-devel] Popping noise on HP dv6000z (CX20549) running x86 kernel
by enigma_0Z 08 Apr '07

08 Apr '07

Here's my situation: If I play a game (any game, in particular, however, neverball/putt or sauerbraten), the sound has these little soft "pop" noises happening so quick per second I cannot count them. This is when I'm running on an x86 kernel, however, when I run an x86_64 kernel, these are not present. I've got a 64-bit processor, specifically an AMD Sempron 3500+ Does Anyone know why? I've got a conexant CX20549 in my laptop. Thanks, enigma

1 1

[alsa-devel] dont knw what this error means
by Ashlesha Shintre 06 Apr '07

06 Apr '07

Hi, I am getting the following error when I try to playback a raw sample file: "ALSA lib pcm.c:7216snd_pcm_set_params) Unable to get period size for PLAYBACK: Invalid argument" Does anyone know what this means? Thanks Ashlesha.

2 1

[alsa-devel] alsa+saa7134 sound problem
by aa 05 Apr '07

05 Apr '07

please read marco007 posts my english is so bad http://forums.gentoo.org/viewtopic-t-527329-postdays-0-postorder-asc-start-… tnx

2 1

[alsa-devel] Sampling rate limited to 48 kHz
by Marek Ławicki 05 Apr '07

05 Apr '07

Hi, I have Turtle Beach Catalina Card (Envy24HT-S, VT1616 + WM8728) which I belive is exactly the same as Mad Dog Entertainer 7.1 ( http://techreport.com/reviews/2004q1/maddog-entertainer/index.x?pg=2 ) Card is recognized as Chaintech AV-710 but works very well ( so far I tested analog out through WM8728 and digital out ). My problem is : I can't set sampling rate higher than 48000 on SPDIF out. I know this card can go higher because : 1. It can go higher under Windows (High Sample Rate 2-channel mode) 2. If I "flash" eeprom with M-Audio Revolution 7.1 settings card can sync with my external DAC up to 96 kHz (DAC limit) and I can play 96kHz .wav file. This is not the way to go for me (analog part and SPDIF-in is lost) I found this : ice1724.c:390:static int get_max_rate(struct snd_ice1712 *ice) ice1724.c-391-{ ice1724.c-392- if (ice->eeprom.data[ICE_EEP2_ACLINK] & VT1724_CFG_PRO_I2S) { ice1724.c-393- if ((ice->eeprom.data[ICE_EEP2_I2S] & 0x08) && !ice->vt1720) ice1724.c-394- return 192000; ice1724.c-395- else ice1724.c-396- return 96000; ice1724.c-397- } else ice1724.c-398- return 48000; ice1724.c-399-} ice1724.c-400- Tried to play with it, but no luck - I'm not developer :-) How can I help with making ice1724 driver even better ? Thanks, Marek # cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.14rc1. Compiled on Apr 2 2007 for kernel 2.6.18.6. # cat /proc/asound/card0/ice1724 Chaintech AV-710 at 0xd000, irq 11 EEPROM: Subvendor : 0x12142417 Size : 28 bytes Version : 1 System Config : 0x42 ACLink : 0x2 I2S : 0x10 S/PDIF : 0xc3 GPIO direction : 0xff GPIO mask : 0xff GPIO state : 0xff Extra #18 : 0x1 Extra #19 : 0x8 Extra #20 : 0x0 Extra #21 : 0x0 Extra #22 : 0x0 Extra #23 : 0x0 Extra #24 : 0x0 Extra #25 : 0x0 Extra #26 : 0x0 Extra #27 : 0x0 Registers: PSDOUT03 : 0x00000000 CCS00 : 0x00 CCS01 : 0xa0 CCS02 : 0x00 CCS03 : 0x00 CCS04 : 0x42 CCS05 : 0x02 CCS06 : 0x10 CCS07 : 0xc3 CCS08 : 0x00 CCS09 : 0x00 CCS0a : 0x00 CCS0b : 0x00 CCS0c : 0x00 CCS0d : 0x0a CCS0e : 0x00 CCS0f : 0x00 CCS10 : 0x37 CCS11 : 0x06 CCS12 : 0x01 CCS13 : 0x80 CCS14 : 0x00 CCS15 : 0xea CCS16 : 0xff CCS17 : 0x00 CCS18 : 0xff CCS19 : 0x00 CCS1a : 0x00 CCS1b : 0x00 CCS1c : 0x00 CCS1d : 0x00 CCS1e : 0x2a CCS1f : 0x00 MT00 : 0x00 MT01 : 0x08 MT02 : 0x00 MT03 : 0x08 MT04 : 0x5a MT05 : 0x08 MT06 : 0x21 MT07 : 0x82 MT08 : 0x00 MT09 : 0x00 MT0a : 0x00 MT0b : 0x00 MT0c : 0x00 MT0d : 0x00 MT0e : 0x00 MT0f : 0x00 MT10 : 0x40 MT11 : 0x1f MT12 : 0xa8 MT13 : 0x0d MT14 : 0x2f MT15 : 0x78 MT16 : 0x00 MT17 : 0x00 MT18 : 0x80 MT19 : 0x03 MT1a : 0x00 MT1b : 0x00 MT1c : 0xff MT1d : 0x07 MT1e : 0x00 MT1f : 0x00 MT20 : 0x20 MT21 : 0x01 MT22 : 0xac MT23 : 0x0d MT24 : 0xb7 MT25 : 0x7f MT26 : 0xff MT27 : 0x07 MT28 : 0x00 MT29 : 0x00 MT2a : 0x00 MT2b : 0x00 MT2c : 0x00 MT2d : 0x00 MT2e : 0x00 MT2f : 0x00 # lspci -vvv 00:0b.0 Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01) Subsystem: VIA Technologies Inc. AMP Ltd AUDIO2000 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at d000 [size=32] Region 1: I/O ports at cc00 [size=128] Capabilities: [80] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-

2 5

Re: [alsa-devel] [Alsa-devel] Quality resampling code for libasound
by Takashi Iwai 05 Apr '07

05 Apr '07

At Wed, 21 Mar 2007 08:35:22 +1100, Jean-Marc Valin wrote: > > >> Well, I use that type because that's what is used in the API. And the > >> reason I use it in the API is because this code is meant to work even on > >> platforms with 16-bit integers (e.g. TI C5X DSPs) and no C99 compiler. > >> If that's causing problem, I guess you could still use unsigned int with > >> no problem... > > > > Don't worry, alsa-lib would be very unlikely ported to such an > > architecture. > > Well, my code has to run on those architectures, and it's much simpler > if I don't need to change it for ALSA. Now if you don't want the > spx_uint32_t in the plugin code, then feel free to change that. OK, as long as it's in alsa-plugins repository, I basically don't care. But, for merging it to alsa-lib, I'd like to change the code very much (including coding-style unification). Anyway, I applied your latest codes to HG tree now (with the removal of samplerate.h). Thanks! Takashi

3 34

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Stefan de Konink 05 Apr '07

05 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Johannes Berg wrote: > On Wed, 2007-04-04 at 20:42 +0200, Stefan de Konink wrote: > >>> /* >>> * For input, we need to do a graceful stop; if we abort >>> * the DMA, we end up with leftover bytes that corrupt >>> * the next recording. To do this we set the S0 status >>> * bit and wait for the DMA controller to stop. Each >>> * command has a branch condition to >>> * make it branch to a stop command if S0 is set. >>> * On input we also need to wait for the S7 bit to be >>> * set before turning off the DMA controller. >>> * In fact we do the graceful stop for output as well. >>> */ >> Check, I have that. > > Hm. Then I don't know what could be causing this. Does it happen all the > time or just intermittently? With every OSS app out there... but native alsa works fine. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFBwQYH1+F2Rqwn0RCi2dAJ9Vlel3cz0PAUMvgYi7L2Nd3XCc9wCeJG9H NT+AsNRL91Dm1y9Dlch75PU= =xxif -----END PGP SIGNATURE-----

1 0

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Stefan de Konink 04 Apr '07

04 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Johannes Berg wrote: > On Wed, 2007-04-04 at 20:31 +0200, Stefan de Konink wrote: > >> In lsmod powermac is not loaded. The 'strange' thing I found, is that >> even without snd-pcm-oss or aoss I get garbage. At that moment I wonder >> what emulation layer is used. > > Oh, I see. There was a bug in the i2sbus setup, does the i2sbus-pcm.c > file (sound/aoa/soundbus/i2sbus/i2sbus-pcm.c) contain the following > comment at around line 380: Something I must note: recording works. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGE/mcYH1+F2Rqwn0RCiYeAJ9h+F1tCdS/cyNbaXoVueFBXX09PgCdGfAp rRH4y2U/E/SBIHtwobJjVI4= =FdSb -----END PGP SIGNATURE-----

1 0