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

[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

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: > /* > * 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. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGE/F+YH1+F2Rqwn0RCtRLAJ0VTYJlaivU3gC0toB7cKI7AYBz6QCfV5AW BO+B/PhvRdxr+asrfI8f9uA= =0LCT -----END PGP SIGNATURE-----

1 0

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Takashi Iwai 04 Apr '07

04 Apr '07

At Wed, 04 Apr 2007 19:18:48 +0200, Johannes Berg wrote: > > On Wed, 2007-04-04 at 19:10 +0200, Takashi Iwai wrote: > > > > > To make sure, check /proc/asound/card0/pcm0p/sub0/hw_params has no > > > > "OSS" entry when you're playing via aoss. If a line like "OSS Format" > > > > appears there, it is still kernel oss-emulation. > > > > > > OSS Format is not in there. > > > > Fine. Then it smells more. > > > > Johannes, any known / possible problem with OSS emulation using aoa > > driver (especially regarding endianness)? > > snd-pcm-oss you mean? Both snd-pcm-oss and aoss wrapper seem not working for Stefan's machine. Maybe a problem specific to a certain model? Takashi > No, it's working fine, the contents of that file is (mplayer -ao oss): > > access: RW_INTERLEAVED > format: S16_BE > subformat: STD > channels: 2 > rate: 44100 (44100/1) > period_size: 1024 > buffer_size: 16384 > tick_time: 10000 > OSS format: S16_BE > OSS channels: 2 > OSS rate: 44100 > OSS period bytes: 4096 > OSS periods: 16 > OSS period frames: 1024 > > while with alsa it is (rhythmbox/gstreamer): > > access: MMAP_INTERLEAVED > format: S16_BE > subformat: STD > channels: 2 > rate: 44100 (44100/1) > period_size: 1024 > buffer_size: 8192 > tick_time: 10000 > > and with aoss (aoa mplayer -ao oss, snd-pcm-oss not loaded): > access: MMAP_INTERLEAVED > format: S16_BE > subformat: STD > channels: 2 > rate: 44100 (44100/1) > period_size: 1024 > buffer_size: 8192 > tick_time: 10000 > > > Don't see a problem at all, working well for me.

2 1

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Takashi Iwai 04 Apr '07

04 Apr '07

At Wed, 04 Apr 2007 19:12:49 +0200, Stefan de Konink wrote: > > Takashi Iwai wrote: > > I meant the comparison between the working state with ALSA apps and > > the non-working state with OSS apps... > > Lets put it this way: > mplayer -ao oss: noise > mplayer -ao alsa: nice sound And the comparison of parameters? You can get it in /proc/asound/card0/pcm0p/sub0/* files as I already mentioned. Diff them between two different stats. Takashi

1 0

Re: [alsa-devel] Alsa OSS - who is maintaining it?
by Takashi Iwai 04 Apr '07

04 Apr '07

At Wed, 04 Apr 2007 18:57:11 +0200, Stefan de Konink wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Takashi Iwai wrote: > > Hm, then I suspect rather it's a problem in the aoa driver side. > > > > To make sure, check /proc/asound/card0/pcm0p/sub0/hw_params has no > > "OSS" entry when you're playing via aoss. If a line like "OSS Format" > > appears there, it is still kernel oss-emulation. > > OSS Format is not in there. Fine. Then it smells more. Johannes, any known / possible problem with OSS emulation using aoa driver (especially regarding endianness)? > > After you confirm it's a native ALSA in the driver execution, compare > > the parameters there between the working status (using ALSA API) and > > non-working status (OSS API). > > I never have had the aoa driver working with OSS. I'm using 1.0.14_rc3. I meant the comparison between the working state with ALSA apps and the non-working state with OSS apps... Takashi

1 0

[alsa-devel] Individual PCM stream control
by Nagalla, Hari 04 Apr '07

04 Apr '07

Hello, I am new to ALSA, so some help from experienced folks would help.. We are trying to develop ALSA support for our DSP based mixer. In our architecture DSP performs the mixing, sample rate conversion etc. My question is how, can does the user space applications exercise controlling individual PCM stream to the mixer? Ex: individual stream gain control, individual stream mute, etc.. Any user space example code would be useful too.. Thanks Hari

2 3