Re: [Alsa-devel] MPU401 broken in CVS
At Fri, 24 Jan 2003 20:01:45 + (GMT), Chris Rankin wrote: Hi, I think that there might be some header file changes to commit in CVS too. thanks, it was simply a typo. fixed now. Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] add additional PnP id to sb16.c for sb16 'value'
At 27 Jan 2003 00:20:33 +1100, Nick Begg wrote: Hello All, I had to add an additional id to the list in sb16.c to get it to recognise my Creative Soundblaster 16 PnP 'value' (i'd never heard of it before the other day).. Does this seem correct? Patch is against alsa 0.9.0rc6 thanks, applied to cvs now. Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
At Fri, 24 Jan 2003 22:24:43 +0100, Tais M. Hansen [EMAIL PROTECTED] wrote: now comes the patch of the week: idx_detect=1 : like test7. perhaps not perfect. No sound, so you're right. hmm, it should produce some sounds. I just gave it another try with aplay. Bad idea; froze the system. Something's really wrong with the test8-patch. ok. now, i rewrote the patch completely again. the module options was removed again. here we go... Takashi via-pointer-test9.dif Description: Binary data
Re: [Alsa-devel] IRQ trouble...[notices]
Pieter Palmers wrote:
Other stuff:
--cut here--
//bytes[0] = 0x04;
//bytes[1] = 0x00;
//err = snd_sam9407_init_command(sam, sam-system_io_queue,
// bytes, 2, buffer, 2, -1);
--comment--
-- This is wrong syntax. There should be:
err = snd_sam9407_init_command(sam, sam-system_io_queue, bytes, 2,
buffer, 1, 0x00)
where 0x00 is acknowledge, and only then you receive another 0x00 as
message, as this could be some status or something.
All received messages are in form of ACK [message], where ACK is
mandatory, and message is optional. Only when ACK 0, driver will wait
for interrupt to arrive. Following code should then be removed.
--comment--
sam-writeCtrl(sam,0x04);
sam-writeCtrl(sam,0x00);
i=0;
while (sam-readCtrl(sam) (17) i1000) {
i++;
udelay(100);
}
if (i=999) {
snd_printk(sam9407: timeout\n);
}
buffer[0]=sam-readData8(sam);
i=0;
while (sam-readCtrl(sam) (17) i1000) {
i++;
udelay(100);
}
if (i=999) {
snd_printk(sam9407: timeout\n);
}
buffer[1]=sam-readData8(sam);
udelay(1000);
snd_printk(sam9407: returns %02X %02X\n,buffer[0],buffer[1]);
/*if (err)
goto __error;
2191:SAM Write to CONTROLvalue 0B
2194:SAM Read from CONTROLvalue 80
2197:SAM Write to CONTROLvalue 00
2200:SAM Read from CONTROLvalue 80
2203:SAM Write to CONTROLvalue 02
2206:SAM Read from CONTROLvalue 80
2209:SAM Write to CONTROLvalue 00
2212:SAM Read from CONTROLvalue 80
2215:SAM Write to CONTROLvalue 00
2218:SAM Read from CONTROLvalue 80
2221:SAM Write to CONTROLvalue 57
2224:SAM Read from CONTROLvalue 80
2227:SAM Write to CONTROLvalue 6B
2230:SAM Read from CONTROLvalue 80
2232:SAM Read from CONTROLvalue 00
2234:SAM Read from DATA8value 10*/
You are loading microcode to address (fixed offset!!) 0x0200, page
0x00, length 0x6b57 _words_ (equals 54958 bytes).
It looks you should receive acknowledge with value 0x10, with no
message. IMHO value 0x10 (ACK) should be delivered witn an interrupt?
Hm... perhaps you need to clear interrupts (read data register) on
maestro side?
Maybe this is happening:
- reset SAM9407 (sam generates spurious interrupt)
- Maestro detects interrupt and raises IRQ flag and IRQ pin (or maybe
it still has IRQ pending)
- Nobody clears Maestro IRQ flag and its IRQs are stuck...
- When SAM9407 raises its interrupt line, Maestro doesn't raise IRQ
line (IRQ overrun), because its previous IRQ flag is not cleared
The strange thing is that with the same driver code, I'm able to
generate both correct and incorrect operation:
When using only the driver, ie modprobe snd-isis, then load the
bootcode through HWDEP, the HWDEP bootload fails. But when using the
maxiinit, ie modprobe snd-isis, run maxiinit in user space, then load
code through HWDEP, the HWDEP bootload succeeds. In the first case the
driver doesn't catch any interrupts, while in the second case it does
catch them.
I must note that after running maxiinit, the card is already in the
operational state I want it to be. But I want to use the HWDEP
interface to get to this state, not the maxiinit app.
Do you have the same IRQ management (on whole IRQ chain
(sam-maestro-[CPU]) regarding stuck IRQs?
Uros: the sam9707 on the ISIS doesn't seem to send a checksum, is this
possible? I also had to modify your driver at some points where it
relied on card-specific details. I'll attach the code.
Yes, this can be specific to ews64 microcode. Looking at sam9407-1.0.0
sources from Gerd, I see that this feature is unique to ews64.
The most significant changes are:
- Callbacks for any IO operation (instead of inw type calls) to
support the maestro way of transferring things. Those are verfied
working
Great - by using SAM ops we can abstract driver to generic one.
- I don't know why, but I wrote my own main SAM module (snd-sam9407),
while you already provided sam9407_lib. But both are pretty much the
same.
Usually, toplevel modules are only those which describe cards. For
example, you have mpu40_lib module, which can be used with toplevel
mpu401 card or i.e. sb16 toplevel module. For example, my ews64 uses
modules:
- ews64 (toplevel module)
-sam9407_lib (this could be renamed to sam9x07_lib :)
- some generic i2c stuff
- ... etc
If I installed (i.e.) ISIS card which uses:
- meastro_lib
- sam 9x07_lib
alongside ews64, then those two cards could share one generic module
(sam9407_lib in our example). There is no card with only sam9407 chip
onboard, but we would make toplevel sam9407 in case there is one, and it
would use sam9407_lib.
- replaced the bootcode
- modified the userspace bootloader (too many assumptions, i.e. about
firmware size and start offset and so
[Alsa-devel] Re: current alsa cvs needs patch on ppc
At Sat, 25 Jan 2003 17:13:11 -0500 (EST), Jack Howarth wrote: Takashi, The current alsa cvs needs the following patch on ppclinux to prevent unresolved symbols in snd-pcm.o... thanks, fixed on cvs. ciao, Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [Survey] headphone - master volume swap -- which codec chip?
At Fri, 24 Jan 2003 12:19:03 +0100, Pieter Palmers wrote: Takashi Iwai wrote: At Fri, 24 Jan 2003 11:53:04 +0100, Pieter Palmers wrote: I experience another problem regarding AC97. I have a Maestro2e based board, with an ESS ES1918 codec attached. But the AC97 code seems to recorgnise it as a Sigmatel Codec. this seems somehow irrelevant, but i can check if you give me the output of ac97#0 and ac97#0regs proc files. Takashi it isn't much of a problem, but for the fact that chip-specific controls aren't built correctly. For example: I get a 'surround volume' controle, whilst the codec has only one DAC. Also I have 3D controls, a feature that isn't present on the codec. well, EXTID (0x28) shows actually the bit 0x80, which means that the chip has surround support. this is really a system-dependent quirk. The fact is that the VID registers indicate that it is a Sigmatel codec... maybe ESS just put their stamp on a sigmatel codec? yeah, perhaps an OEM chip? Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] alsa-lib resamping error
At Thu, 23 Jan 2003 17:20:02 +0100, I wrote: At Wed, 22 Jan 2003 12:38:31 -0500, Paul Davis wrote: if you try to play a 22.05kHz stream on hardware that supports 32kHz and 44.1kHz but not 22.05kHz, alsa-lib's plughw layer chooses to use 32kHz and resamples. this seems like an error to me: it would be much better to choose 44.1kHz and do simple integer resampling. that is: the search for the best rate should first try integer multiples and divisors of the desired rate, not the closest rate. agreed, it would be better. but... errm... changing this in alsa-lib is like going into a big labyrinth for me :) and after a long wandering in the labyrinth, the changes are on cvs now (both for alsa-driver and alsa-lib). the new code will try the integer multiples at first. i hope this works correctly... Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] asoundrc problem
Hi All,
I get this errormessage for the multi configuration below:
Broken configuration: no configurations available: Invalid argument
pcm.multi {
type multi;
slaves.a.pcm hw:0,0,0;
slaves.a.channels 8;
slaves.b.pcm hw:1,0,0;
slaves.b.channels 8;
bindings.0.slave a;
bindings.0.channel 0;
bindings.1.slave a;
bindings.1.channel 1;
bindings.2.slave a;
bindings.2.channel 2;
bindings.3.slave a;
bindings.3.channel 3;
bindings.4.slave a;
bindings.4.channel 4;
bindings.5.slave a;
bindings.5.channel 5;
bindings.6.slave a;
bindings.6.channel 6;
bindings.7.slave a;
bindings.7.channel 7;
bindings.8.slave b;
bindings.8.channel 0;
bindings.9.slave b;
bindings.9.channel 1;
bindings.10.slave b;
bindings.10.channel 2;
bindings.11.slave b;
bindings.11.channel 3;
bindings.12.slave b;
bindings.12.channel 4;
bindings.13.slave b;
bindings.13.channel 5;
bindings.14.slave b;
bindings.14.channel 6;
bindings.15.slave b;
bindings.15.channel 7;
}
I have two Terratec EWS88MT (ice1712)
Any Hints?
Oliver Schrempf *** eMail [EMAIL PROTECTED]
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] [PATCH] Envy24HT
One of the attached patches correct a problem with the surround speakers with the AUDIO2000 Envy24HT based board. The other patch adds the ICE1724.conf file to the alsa-lib/src/conf/cards directory. patch-envy24ht-surroundfix.diff Description: Binary data patch-envy24ht-addconf.diff Description: Binary data -- James Stafford mailto:[EMAIL PROTECTED] Advanced Micro Peripherals Ltd Unit 17 Sedgeway Business Park Witchford Cambridge CB6 2HY Tel: +44 1353 659 500 Fax:+44 1353 659 600
Re: [Alsa-devel] [PATCH] Envy24HT
Hi, At Mon, 27 Jan 2003 13:31:38 +, James Stafford wrote: One of the attached patches correct a problem with the surround speakers with the AUDIO2000 Envy24HT based board. The other patch adds the ICE1724.conf file to the alsa-lib/src/conf/cards directory. thanks, applied to cvs now. Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] asoundrc problem
At Mon, 27 Jan 2003 14:09:03 +0100 (CET), Oliver Schrempf wrote: Hi All, I get this errormessage for the multi configuration below: Broken configuration: no configurations available: Invalid argument doesn't it work with the pcm plug:multi ? Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] xine cvs alsa
For a week, maybe a bit more (I didn't watch any movies for over a week, and haven't had time to try searching cvs to pin down the date) xine has been dying when I try to watch movies in 4.0, 5.0, or 5.1. Stereo works without any problems, though. Here's the error message: audio_alsa_out: Audio Device name = surround40 audio_alsa_out: Number of channels = 4 ALSA lib dlmisc.c:107:(snd_dlsym_verify) unable to verify version for symbol _snd_pcm_hook_ctl_elems_install ALSA lib pcm_hooks.c:527:(snd_pcm_hook_add_conf) symbol _snd_pcm_hook_ctl_elems_install is not defined inside (null) xiTK received SIGSEGV signal, RIP. Aborted Is this an API change, xine doing something shifty that it got away with up until now, or something else entirely? Anything I can do to work around it? Movies just aren't the same in stereo... :) Thanks, Ragnvald Maartmann-Moe IV --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] IRQ trouble...[notices]
Pieter Palmers wrote:
There is one remark though: Your driver oops at some times (null
pointer dereference), ie when doing: (sam_ucode.c)
err = snd_sam9407_init_command(NULL, bytes, 7, NULL, 0, -1);
The problem is in the magic_cast:
When calling this with queue=NULL, the magic_cast causes an oops,
which is pretty normal I guess. I wonder why it didn't in your tests.
/* transmit init command sequence to sam9407 */
int snd_sam9407_init_command(sam9407_io_queue_t * queue,
u8 *cmd_buffer, int cmd_bytes,
u8 *rcv_buffer, int rcv_bytes,
int ack)
{
sam9407_t *sam = snd_magic_cast(sam9407_t, queue-sam, return
-EINVAL);
signed long end_time;
int err;
unsigned long flags;
if (queue) {
(...)
Yikes! This is an unfinished cleanup stuff. I was trying to get
rid all the queue setup overhead when command actually didn't expect any
response (when ACK = -1). These commands should be called with:
/* transmit init command sequence to sam9407 */
int snd_sam9407_init_command(sam9407_t *sam,
sam9407_io_queue_t * queue,
u8 *cmd_buffer, int cmd_bytes,
u8 *rcv_buffer, int rcv_bytes,
int ack)
(The same applies to snd_sam9407_command())
Following this, calls to these two commands should be fixed to use
*sam variable. sam9407_t *sam should be removed from
sam9407_io_queue_t. In snd_sam9407_queue_prepare() function, remove test
for (ack = 0) and allways use
queue-error = -EIO;
queue-ack = ack 0xff;
set_bit(SAM_QUEUE_WAIT_ACK, queue-status);
set_bit(SAM_QUEUE_BUSY, queue-status);
codepath.
Commands without acknowledge should now be called with
snd_sam9407_[init_]command(sam, NULL, buffer, num_cmd, , X, X);
where X doesn't matter.
Uros.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 27 January 2003 11:42, Takashi Iwai wrote: I just gave it another try with aplay. Bad idea; froze the system. Something's really wrong with the test8-patch. ok. now, i rewrote the patch completely again. the module options was removed again. here we go... Ok. Hope you had a great weekend. :) - - Fresh cvs update. Recompiled installed alsa-lib and alsa-util. - - POINTER_DEBUG enabled. No sound from aplay but it had a lot of complaints for me. Two files attached. - -- Regards, Tais M. Hansen OSD -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iQIVAwUBPjVFZoIvLOJqwYc4AQKPzQ/8DJDYSkSdi70eIaQ/4seWEiN3eC6gOhuZ 5gXmWoLFDvOTaYf4EI/TlXrrWUYqIjDYn3m6PtS4Enn0zXe5FBztguQu8vOMYGcS OSLaC1Po6gjOgI/klEgawn/G0W4ffn8YVXSYxNJGuYXYmZa2QOcYfbN/MpqH/bnj NPBc8DFyKDnMTspsz0Fr+bL8mfrJnFQzSagV5mKIGDZVExFzqzQWyU2tWpOdoOft i6OB4CnuGZWhQOmnK8fAyijfWn8m+g7UJ7UfcjhagcQnvf7xoUov5kjzZ5Js4ZaY 5jKEow9UF2vij7GfpLidHIi+LyvTybOr1YzXEFCMpb/2qt93xavCdBh1P76xRSTo By7oN6u5wV3rYBP+V3twxKff3g5Q5EVoJhCj4RKjqFIOzQdGsqlF2JZ5P+ODI37I AxL4BBKzIklKKQh0W+PBQoxlJWv+OYVFUUclDjSDYRo672IwvdrIUO4TBllawWhK 5A4LYWHeoIebzA3PFKUhdlRLa/3kpGZPWeOEbsDuJnB/9FTMiCxo6AUd/9MJ3PUC GUV8z40FkIei589mB866PKdhWx567/dJaRgcezKWtY5JWNjDJpDjP34Y/sGwodku Y1YKgqKRScrls+G/jzhzT4XXNkYE81BVF8/o6ClwQUXNUfuM0T6DcCKeHRjWYAHP yqqN7mvVJj0= =D2I5 -END PGP SIGNATURE- alsa-aplay-log-test9.txt.gz Description: GNU Zip compressed data alsa-aplay-stdout-test9.txt.gz Description: GNU Zip compressed data
Re: [Alsa-devel] xine cvs alsa
i've had this under mandrake 9.0 with the supplied release too :( m~ [EMAIL PROTECTED] wrote: For a week, maybe a bit more (I didn't watch any movies for over a week, and haven't had time to try searching cvs to pin down the date) xine has been dying when I try to watch movies in 4.0, 5.0, or 5.1. Stereo works without any problems, though. Here's the error message: audio_alsa_out: Audio Device name = surround40 audio_alsa_out: Number of channels = 4 ALSA lib dlmisc.c:107:(snd_dlsym_verify) unable to verify version for symbol _snd_pcm_hook_ctl_elems_install ALSA lib pcm_hooks.c:527:(snd_pcm_hook_add_conf) symbol _snd_pcm_hook_ctl_elems_install is not defined inside (null) xiTK received SIGSEGV signal, RIP. Aborted Is this an API change, xine doing something shifty that it got away with up until now, or something else entirely? Anything I can do to work around it? Movies just aren't the same in stereo... :) Thanks, Ragnvald Maartmann-Moe IV --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel -- iriXx www.iriXx.org copyleft: creativity, technology and freedom? [EMAIL PROTECTED] www.copyleftmedia.org.uk _ ( ) ascii ribbon against html email X / \cat /dev/sda1 /dev/dsp *** stopping make sense *** --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [linux-audio-dev] interesting info regarding hdsp behavior
I've been messing with hdsp and found out an interesting issue. After installing the driver for the first time onto the xp machine I also had no sound coming out of the soundcard even though totalmix app showed levels to be up. After clicking on the levels and/or moving them a bit, suddenly the sound was there (as if the default values were there only in the app itself, but did not affect the actual levels on the card until they were moved for the first time). I was wondering maybe this is the problem we're having in Linux, where the card loads just fine, but for some reason there is no sound until a reboot has taken place. this problem has already been fixed. it was caused by a missing register write on intel systems (the relevant one was there for PPC systems). marcus fixed this, oh, maybe 2-3 months ago. --p --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
At Mon, 27 Jan 2003 15:42:43 +0100, Tais M. Hansen [EMAIL PROTECTED] wrote: [1 text/plain; iso-8859-1 (quoted-printable)] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 27 January 2003 11:42, Takashi Iwai wrote: I just gave it another try with aplay. Bad idea; froze the system. Something's really wrong with the test8-patch. ok. now, i rewrote the patch completely again. the module options was removed again. here we go... Ok. Hope you had a great weekend. :) - - Fresh cvs update. Recompiled installed alsa-lib and alsa-util. - - POINTER_DEBUG enabled. No sound from aplay but it had a lot of complaints for me. Two files attached. ok, the patch was buggy. but any sounds must come out. please check your mixer configuration. the fixed patch below: same as test9 but more verbose with POINTER_DEBUG. Takashi via-pointer-test10.dif Description: Binary data
[Alsa-devel] Re: [Alsa-user] No sound on Extigy
At Fri, 24 Jan 2003 00:16:25 -0500, Jean-Marc Valin wrote: [1 text/plain; ISO-8859-1 (quoted-printable)] if the original usb-audio driver doesn't work with plughw like above, please try the attached patch. I tried the patch, but I still can't play anything other than 48000, 2 channels and 48000, 4 channels (tried the other ones listed in /proc/asound/card0/stream0 but they didn't work). Any way I can at least get 44.1 kHz/stereo and 8000/mono working? there was a bug in the patch. i already committed the fixed version to cvs. please update the cvs version and give a try again (you'll need to plug layer anyway, because extigy doesn't support two-channels 44100 hz). Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] ens1371 SPDIF feed-trough
Hi all, According to the Creative labs specs, the CT4751 (ens1371) supports SPDIF direct feedtrough for DTS or DD. Does the ALSA driver support this? If not, any clue on how to implement this? If it does, what do I use to test it? Pieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] asoundrc problem
On Mon, 27 Jan 2003, Takashi Iwai wrote: Broken configuration: no configurations available: Invalid argument doesn't it work with the pcm plug:multi ? Sorry, but I can't find any documentation on plug:multi? How do I have to to use it? Oli --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] asoundrc problem
On Mon, 27 Jan 2003, Oliver Schrempf wrote: On Mon, 27 Jan 2003, Takashi Iwai wrote: Broken configuration: no configurations available: Invalid argument doesn't it work with the pcm plug:multi ? Sorry, but I can't find any documentation on plug:multi? How do I have to to use it? aplay -Dplug:multi It's device description/name for alsa-lib. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] buffer_size and period_size
Hi! I've tried to port some aplication from old ALSA-0.5.x to the new alsa library interface. I'm not an expert in the sound programming and available documentation seems to be rather poor in term of explaining the main concept. I would like to fully understand the exact meaning of buffer_size and period_size and how can I compute the final latency in the full duplex processing from these variables. Thank you. -- jozef kosoru [zyzstar] [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 27 January 2003 16:15, Takashi Iwai wrote: No sound from aplay but it had a lot of complaints for me. Two files attached. ok, the patch was buggy. but any sounds must come out. please check your mixer configuration. It seems okay. Just to make sure I reverted the patch and recompiled. Aplay played several minutes without any errors at all. I also let ogg123 play for about 10 minutes. Had a few pops and an equal amount of fails in syslog. Pretty much the same as what I started out with after your initial via-fix. I've attached the ogg123 logoutput anyway. the fixed patch below: same as test9 but more verbose with POINTER_DEBUG. Attached 2 files from testing with aplay. - -- Regards, Tais M. Hansen OSD -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iQIVAwUBPjVl+YIvLOJqwYc4AQIvqw/+Kvsr+jz1JxEKkynD4R5wDFeh5suycJ3r yCTsEliaaTw35w5+6wpGqHcIGcCHcugqIMOaWrkfseNV3Sghm3rhVAoisMHZDCq/ lhifJ1uj2i1v2gwtkrBABv4QXHZ4mk1iRSRk4rYuqho2tHlp9qYs6g8OAXclk6Ih gYDt3/Q4ceqWPhT9r0s31/nB4yr7rQpkCxO40fY9Ux4aFQFkiHb9Yi4gb2DJ53Zg Ox0GUPUnoMyx61eYJMIDUwdweSMuxopYUnNrU1vCRXwv7Txt7JCAu/afRkK+41gn IrF+Fcof1cBAxfyZrgi4RgrCONKSWSWnhainr2pymVnDbmKFZd7IT9G5I9E5xyPJ tBWsVGkUU8/fbSgA566jd592oM3qP0/uf3tkjnI5+s5rUSWMcAGiQzmBaB08ENMv hfiU2DjQ5Ls8uTpBIy5Qhqv6w3yXeAJZVzav3GNcVQZSikUBcwaS4g4Tf19X0PRr ygKLRB5aoW4O/vZIqbRrBx5rJjITFDYzPGtbp6RMoOf4omqgZHRB+oANHYLGoVfu 2f8sjIGC5isdY4FkXIdehI0g4LPqbxpQczxpreODm4Xfd0IBztUzLs8IpuddsEuy ExkL+1+NHUbqOF1MfxytBWATb+FBucCEACKlm4oVGmqHA90WVNtvCt0Wne0H4oou cn3N3N15LRU= =tiID -END PGP SIGNATURE- alsa-aplay-log-test10.txt.gz Description: GNU Zip compressed data alsa-aplay-stdout-test10.txt.gz Description: GNU Zip compressed data alsa-ogg123-log-orig.txt.gz Description: GNU Zip compressed data
Re: [Alsa-devel] asoundrc problem
Broken configuration: no configurations available: Invalid argument doesn't it work with the pcm plug:multi ? Sorry, but I can't find any documentation on plug:multi? How do I have to to use it? aplay -Dplug:multi It's device description/name for alsa-lib. Thanks for that one, but arecord -Dplug:multi -c16 multitest.wav gives me ALSA lib dlmisc.c:107:(snd_dlsym_verify) unable to verify version for symbol _snd_pcm_plug:multi_open ALSA lib pcm.c:1788:(snd_pcm_open_conf) symbol _snd_pcm_plug:multi_open is not defined inside (null) arecord: main:462: audio open error: No such device or address Oli --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
At Mon, 27 Jan 2003 18:01:42 +0100, Tais M. Hansen [EMAIL PROTECTED] wrote: [1 text/plain; iso-8859-1 (quoted-printable)] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 27 January 2003 16:15, Takashi Iwai wrote: No sound from aplay but it had a lot of complaints for me. Two files attached. ok, the patch was buggy. but any sounds must come out. please check your mixer configuration. It seems okay. Just to make sure I reverted the patch and recompiled. Aplay played several minutes without any errors at all. I also let ogg123 play for about 10 minutes. Had a few pops and an equal amount of fails in syslog. Pretty much the same as what I started out with after your initial via-fix. I've attached the ogg123 logoutput anyway. the fixed patch below: same as test9 but more verbose with POINTER_DEBUG. Attached 2 files from testing with aplay. how about this one? Takashi via-pointer-test11.dif Description: Binary data
Re: [Alsa-devel] asoundrc problem
At Mon, 27 Jan 2003 18:03:21 +0100 (CET),
Oliver Schrempf wrote:
Broken configuration: no configurations available: Invalid argument
doesn't it work with the pcm plug:multi ?
Sorry, but I can't find any documentation on plug:multi?
How do I have to to use it?
aplay -Dplug:multi
It's device description/name for alsa-lib.
Thanks for that one, but
arecord -Dplug:multi -c16 multitest.wav
gives me
ALSA lib dlmisc.c:107:(snd_dlsym_verify) unable to verify version for
symbol _snd_pcm_plug:multi_open
ALSA lib pcm.c:1788:(snd_pcm_open_conf) symbol _snd_pcm_plug:multi_open is
not defined inside (null)
arecord: main:462: audio open error: No such device or address
hmm, there is still a bug in the alsa-lib configuration parser..?
anyway, add the following and try -Dmplug instead as a workaround.
pcm.mplug {
type plug
slave.pcm multi
}
ciao,
Takashi
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] buffer_size and period_size
Paul, So with -p 64 -n 2 settings, what number of bytes of audio data is transferred across the PCI bus between each interrupt? I guess I had mistakenly thought -p was setting the number of bytes. I no longer think that is true. Also, does the number of bytes transferred change based on how many channels are enabled? Or does my RME always transfer 26 channels of data even if I am not using some channels? I am assuming that a card like the RME is a bus master, moves so many bytes, and then interrupts to tell the system that the bytes are there. Is this basically the case? Thanks, Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis Sent: Monday, January 27, 2003 9:32 AM To: Jozef Kosoru Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] buffer_size and period_size I would like to fully understand the exact meaning of buffer_size and period_size and how can I compute the final latency in the full duplex processing from these variables. period_size = frames between interrupts from the hardware buffer size = total frames for the hardware buffer max output latency = buffer_size min output latency = buffer_size - period_size max input latency = period_size + interrupt overhead min input latency = 1 frame + interrupt overhead the latency numbers assume: a) the buffer is generally full b) you process data 1 period at a time c) your s/w keeps up with the h/w d) its an average, computed across a period's worth of data --p --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] asoundrc problem
hmm, there is still a bug in the alsa-lib configuration parser..?
anyway, add the following and try -Dmplug instead as a workaround.
pcm.mplug {
type plug
slave.pcm multi
}
Umpf, sorry. I just realized, that I had a mistake in asoundrc from
playing around with plug:multi.
The error I get now from
arecord -Dmplug -c16 test.wav
as well as from
arecord -Dplug:multi -c16 test.wav
is
arecord: main:462: audio open error: No such file or directory
greetings Oli
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] buffer_size and period_size
Paul, So with -p 64 -n 2 settings, what number of bytes of audio data is transferred across the PCI bus between each interrupt? the period size is always (as with almost all ALSA metrics) in units of audio frames (1 sample for each channel). so with JACK running at -p 64, 64 frames of data are transferred. how many bytes that is depends on the sample width and the number of channels. Also, does the number of bytes transferred change based on how many channels are enabled? Or does my RME always transfer 26 channels of data even if I am not using some channels? its hardware dependent. for the RME, the same amount is always moved, regardless of how many channels are enabled. in the case of the RME Hammerfall series, its more accurate to say that you cannot change the number of channels enabled. this is not true of all other hardware. I am assuming that a card like the RME is a bus master, moves so many bytes, and then interrupts to tell the system that the bytes are there. Is this basically the case? yes. keep in mind that this only covers 1 direction: the interrupt also tells the system that its possible to put data into the hardware buffer. --p --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re[2]: [Alsa-devel] via8235 swaped channels
Friday, January 24, 2003, 6:54:53 PM, you wrote: if someone has VIA8233, VIA8233A, VIA8233C or VIA8235 chipset, could you help the testing of the new driver? the new driver code is found at http://www.alsa-project.org/~iwai/via82xx.c i has VIA8235 and ALC650 codec. After installing new driver from cvs from 20030113, there is following problem: In 5.1-channel dvd playback with xine using surround51 device, i has swapped Rear and Center/lfe channels. RL - Center, RR - LFE this can be fixed just by exchanging Rear and Center/LFE jacks i fixed this with following patch for via82xx.c 812,813c812,815 case 5: slots = (10) | (24) | (58) | (312) | (416); break; case 6: slots = (10) | (24) | (58) | (612) | (316) | (420); break; --- //case 5: slots = (10) | (24) | (58) | (312) | (416); break; //case 6: slots = (10) | (24) | (58) | (612) | (316) | (420); break; case 5: slots = (10) | (24) | (38) | (412) | (516); break; case 6: slots = (10) | (24) | (38) | (412) | (516) | (620); break; I'm not sure that it is alsa problem, xine' may be. TI hmm, it could be due to the setting of ALC650. how is the status of TI Exchange Center/LFE mixer switch? This switch has no effect. Strange. Usually its muted. Now i think this is ALC650 problem. Is there problem exist on via8235 with other codecs? TI the switch above is irrelevant to this behavior. sorry for confusion. TI but there is another register bits, and i fixed it on the cvs. TI please update your alsa-kernel tree via cvs and give a try. cvs from 25.01 don`t change this. as i understand we must to modify bits 15:14 in ALC650 vendor specific register MX6A (Multi-Channel Control). i see that value of this register is always h. in addition, Exchange Center/LFE mixer switch, which must to set MX6A.3=1 do nothing. MX6A still has h value. ALC650 uses following default slot mapping (as in ACÂ’97 spec. rev2.2) if MX6A=h L R SL SR CEN LFE 3 4 7 8 6 9 now i`m again not sure that this is codec problem. can anyone test this with other codec ? Anton Worshevsky --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] level plugin not loaded with current cvs
Takashi Iwai wrote: Hi, At Sat, 25 Jan 2003 12:18:25 +0100, Laurent Georget wrote: [l@localhost l]$ arecord -D ameter -v sound.wav ALSA lib dlmisc.c:107:(snd_dlsym_verify) unable to verify version for symbol _snd_pcm_scope_ameter_open ALSA lib pcm_meter.c:742:(snd_pcm_meter_add_scope_conf) symbol _snd_pcm_scope_ameter_open is not defined inside /usr/local/lib/libameter.so arecord: main:462: audio open error: No such device or address it's due to the check of snd_dlsym(). now pcm_meter.c uses the normal dlsym(), so it should work again on cvs. please give a try. ciao, Takashi Ok now, thanks! Laurent --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] building a mixer
Hi all, is it possible to support multiple mixers in one card? I have the following situation: The card consists of a Maestro2E PCI controller with AC97 codec. On the expansion port of the maestro is a SAM9707 device. I'd like separate mixers for the AC97 and the SAM, because the control names can be very confusing otherwise (i.e. Master volume of Codec does not change Master volume of any SAM output). The card is routed pretty strange: the 2channel codec output is re-sampled and this digital signal is fed into the SAM device for further processing. From it can be output to 2 stereo pairs of outputs (ie 4 mono). But there are also 6 other mono inputs that are routed directly to the SAM device, and can be HW monitored on the SAM's outputs. To make things even more complex: the digital stereo signal is multiplexed with an SPDIF input and two other mono inputs. You can choose which one you want (only one). I'd like the codec mixer separate from the other controls, as this reflects internal structure best. Apart from that, the codec controls are rarely used, because I always use the SAM channels which are better quality. Thanks, Pieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] VIA823x testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 27 January 2003 18:27, Takashi Iwai wrote: how about this one? Still no sound. More logs for you to digest. - -- Regards, Tais M. Hansen OSD -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iQIVAwUBPjXSOYIvLOJqwYc4AQIsHw/9EsI3OH8H4oQhUWjzBQwOxCqd0grsigMC AkY640gaBzw2nlPRoxSOuiofxzyryxFlCLj1KUMh7h4IjUsp5oSU1k2aMESIB5PI GSbT75aIFbEQjLD1db+lKD6Xpi/pxYvqqd5sYvyNqSQjLf3iUdWb+F1sC7W3dYW8 03SLt6M+xgH9lTFWLCkzpIxUufDR4rvIl069Sw+yvJ7fJcTbSTAfodsJksZBJdyD Ef8zMgaHs06ySeR91hr9TWVZAqhtoRNQ6sYO+d7piZoraM4IjAXsdSTKIb9DRLP7 zgo020Z/cVoIHIg+a+Y40pAAGg56WB5O1GMOF3ifQG9DFVRi4isezMS+ZdXHH2a0 mPAEagVhAPEaGfmua0bOMSlU+VVYLc7rDcRGYRHXE4J4t2CdCW8flcbUYmbWpOmr rnR1GkhFXyc0pulOvAACYFoie4bAh8sD4PXBx/GMA6lIohUoiNYkhYEpSqcP1Wku bfSIppVDKzoeoESATJfnsdYivScNx7kuBwU2GfcpqHZV84tNBcoSExoqUMDQLJ2O uD3q7tw7VTMNOq4iHlNb2/TCeCYL8mCzs0ocg+6v1H2y10t8X6QURc8TwE7recqH p//YgBDJcUtKtIWOegwdjb7Ca8KXhm48lv1IBbeowr3ps+G3T6F9o+3vJaTh6eLm qo9xbSE6esM= =p5vV -END PGP SIGNATURE- alsa-aplay-log-test11.txt.gz Description: GNU Zip compressed data alsa-aplay-stdout-test11.txt.gz Description: GNU Zip compressed data
[Alsa-devel] 192khz working for anyone? and RME96 patch broke
First the RME thing: Torger's post-RC6 patch to rme96.c broke double-speed capture, so that there is nasty clipping/Nyquist-type garbage in it. This is definitely in the patch itself - a CVS kernel with an RC6 rme96.c works fine. -- Now for the main attraction. I'm looking for any way to get 192khz audio working. If anyone's gotten it working (under ALSA), I wanna hear how. I tried Audigy 2 with no success. opensource.creative.com now has an Audigy 2 linux driver available, but I don't want to go back to that card, and I don't want to use a non-ALSA driver. Consumer cards are just painful, and Audigy 2 has no 192khz capture hardware, in any case. My next try is the Envy24HT-based (ICE1724) ESI Waveterminal 192X. This is a pro card, much more appropriate for my purposes. It has 192khz capture and playback. The CVS ALSA kernel purports to have basic suppiort for ICE1724 now, but it's not working for me: Bus 0, device 14, function 0: Multimedia audio controller: PCI device 1412:1724 (IC Ensemble Inc) (rev 1). IRQ 9. Master Capable. Latency=64. I/O at 0xef40 [0xef5f]. I/O at 0xec00 [0xec7f]. but then modprobe snd-ice1712 /lib/modules/2.4.18-xfs/kernel/sound/pci/ice1712/snd-ice1712.o: init_module: No such device Any ideas? The vendor and device IDs match the 1724 stuff in ice1712.c, and not being an ALSA or Linux kernel savant, I don't have an intuition where to go from here. I'm perfectly willing to send this card back and try another, if anyone has gotten 192khz ALSA working on it. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] 192khz working for anyone? and RME96 patch broke
On Tuesday 28 January 2003 06.27, Daniel Pouzzner wrote: First the RME thing: Torger's post-RC6 patch to rme96.c broke double-speed capture, so that there is nasty clipping/Nyquist-type garbage in it. This is definitely in the patch itself - a CVS kernel with an RC6 rme96.c works fine. Strange, I did not touch that code specifically. Anyway, so you have tested with an old ALSA and the new driver (rme96.c) and that does not work? Is it double speed capture from analog, or from digital input you are having problems with? /Anders Torger --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
