Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
At Thu, 23 Jan 2003 19:43:52 +0100, Tais M. Hansen <[EMAIL PROTECTED]> wrote: > > [1 ] > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thursday 23 January 2003 19:07, Takashi Iwai wrote: > > > > thanks. > > > > it seems really the index value was not updated correctly by the > > > > chip. > > > > ok, take 4: please try the new one... > > > Same as before, log output attached. :) > > the next one is to put all logs to /var/log/debug. > > and will show more verbose. > > Ok, log output attached, 3 files with loads of gibberish ;). Same behavior > btw. thanks. sigh, this chip is really weird. perhaps in the last patch, the recoverd pointer overtook the actual pointer and got the driver confused. take 6: the calculation of recovered pointer is changed. and the register value of CURRPTR is shown as reference. if it's more acculate, we can refer to it instead... as usual, debug messages appear by enabling DEBUG_POITNER. Takashi via-pointer-test6.dif Description: Binary data
Re: [Alsa-devel] HDSP 9652 MIDI Timing - Much improved, but no Port 1...
At 23 Jan 2003 19:44:49 +, Mark Knecht wrote: > > Paul, Takashi-san and Clemens, >Hi. A couple of days ago Fernando got a new RPM built for Alsa which > includes the recent HDSP 9652 MIDI timing fix that you worked together > on and supplied about 10 days ago. I wanted to report back that the > timing is now much improved. I haven't used it a lot yet, but I am > playing moderately complicated songs now and the timing seems fine. > Thanks. > >There is one problem that has come up new in this release. The HDSP > 9652 has two MIDI ports. With this release I can only get MIDI out on > Port 2. I cannot get MIDI out at all on Port 1. Both ports used to work > on the previous version, albeit with bad timing, so this fix this has > changed this aspect of the driver. could you (or anyone HDSP owner) check the attached patch? >I also tried using kaconnect to look at the connections between > Rosegarden and the alsa_sequencer. It shows that Rosegarden is hooked to > 64:32 External MIDI 0 only. A second group, 64:0 External MIDI 0 shows > up, but kaconnect will not connect to it. I do not know what that means, > but it seems to be part of it. rosegarden developers know better about this... Takashi hdsp-midi.dif Description: Binary data
Re: [Alsa-devel] [PATCH] SC-D70 recording support
At Thu, 23 Jan 2003 19:05:53 +0100 (MET), Clemens Ladisch wrote: > > > This finally adds support for capturing. > > Contrary to what I've written earlier, the mixer controls (capture > selection etc.) *are* supported, because they're on the device's front > panel, not in software. :-) applied to cvs. thanks for your work! 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] amixer question - numid=2
At 19 Jan 2003 10:59:39 +, Mark Knecht wrote: > > Hi, >On my HDSP 9652 system executing the command > > amixer controls > > yields a list that appears to be 166 items long, starting with numid=1 > and ending with numid=166. However, closer study shows numid=2 seems to > be missing. > > Is this an issue with amixer or my card? What function might normally be > associated with numid=2? don't worry, no bug: it's not a mixer control but a control for a PCM stream. that's why amixer doesn't show this element. 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 -- whichcodec chip?
On Fri, 24 Jan 2003, Takashi Iwai wrote: > Hi all, > > there have been bug-reports regarding to the swapping of headphone > and master volumes. > i'd like to ask you to check which AC97 codec chip is used on which > board (or laptop) if you have such a problem. if this happens only on > a certain chip model, we can add a quirk for that. Takashi, this quirk can be done only by detection of subvendor and subsystem from the PCI ID space. It's absolutely irrelevant which AC97 chip is used. Vendor might wire codec in any way. Also, some codecs may swap line-out / headphone out via registers. 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] source tree
Hi, I'm writing a driver for the Maxisound ISIS and I have the following question: how do I get it into my local source tree and get it compiled? I manage to compile the module, but I get 'unresolved depencies': depmod: *** Unresolved symbols in snd-isis.o depmod: snd_pcm_period_elapsed_R464d6116 depmod: snd_ctl_add_R4783579c depmod: snd_card_register_Rec576d24 depmod: snd_malloc_pci_pages_fallback_R391ee959 depmod: snd_device_new_R1ae93b48 depmod: snd_verbose_printk_R49d4e4d1 depmod: snd_pcm_new_R0affc2e1 depmod: snd_mpu401_uart_interrupt_R4ea4dc60 depmod: snd_pcm_format_width_R55eb2175 depmod: snd_kcalloc_R4da9e78a depmod: snd_pcm_set_ops_R5bc58ea3 depmod: snd_ctl_new1_R15f3f808 depmod: snd_free_pci_pages_Rff2abb0b depmod: snd_card_free_R58fc32d2 depmod: snd_ac97_mixer_R68e0ce82 depmod: snd_card_new_R429f855e depmod: snd_pcm_lib_ioctl_Rabc0ac86 depmod: snd_mpu401_uart_new_Refff4aee Aren't these ALSA symbols? What do I change to get this resolved? 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] [Survey] headphone <-> master volume swap -- which codec chip?
At Fri, 24 Jan 2003 12:16:00 +0100 (CET), Jaroslav wrote: > > On Fri, 24 Jan 2003, Takashi Iwai wrote: > > > Hi all, > > > > there have been bug-reports regarding to the swapping of headphone > > and master volumes. > > i'd like to ask you to check which AC97 codec chip is used on which > > board (or laptop) if you have such a problem. if this happens only on > > a certain chip model, we can add a quirk for that. > > Takashi, this quirk can be done only by detection of subvendor and > subsystem from the PCI ID space. yeah, the lspci output is on the query list. > It's absolutely irrelevant which AC97 > chip is used. really? i believe this happens only on certain ac97 chips. for example, ALC202 spec says that ALC202A uses the headphone volume as the "true line out" volume. so, apparently, some ac97 chips "recommend" this behavior. let's see... > Vendor might wire codec in any way. Also, some codecs may > swap line-out / headphone out via registers. this is a different case, imo. the problem is that we have no chance to detect/switch them, either manually or automatically. a general solution would be to add an ac97 control switch to swap them. then the accssed registers are exchanged internally according to this control. but it isn't bad to know which chips and which machines have this problem, so that we can add quirks to turn on this switch automatically. 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] amixer question - numid=2
Thanks! On Fri, 2003-01-24 at 11:15, Takashi Iwai wrote: > At 19 Jan 2003 10:59:39 +, > Mark Knecht wrote: > > > > Hi, > >On my HDSP 9652 system executing the command > > > > amixer controls > > > > yields a list that appears to be 166 items long, starting with numid=1 > > and ending with numid=166. However, closer study shows numid=2 seems to > > be missing. > > > > Is this an issue with amixer or my card? What function might normally be > > associated with numid=2? > > don't worry, no bug: > > it's not a mixer control but a control for a PCM stream. > that's why amixer doesn't show this element. > > > 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] VIA8235 with ALC650
Dear Takashi Iwai, Thursday, January 16, 2003, 12:21:42 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 >> > the new driver can (hopefully) play multiple streams simultaneously on >> > VIA8233, VIA8233C and VIA8235, but NOT on VIA8233A. >> >> It's worked, but second stream plays only left channel. >> >> Almost all OSS application such as games (UT, tux-racer and other) now producing >> cracking and skipping sound. Only XMMS OSS-plugin plays good. OSS-sound was good >> with rc6. TI> does the patch below change something? There are no change in apps which played good before (all tested apps with alsa output, mpg123 and xmms oss-plugin). In games sound with patch playing faster and higher, but as i can hear with same bad quality. RC6 do not has such problems. Any idea? Can you explain me in which units we must calculate rate under mask 0xf in next code ? Are there any special values for it (such as 0xf)? outl((runtime->format == SNDRV_PCM_FORMAT_S16_LE ? VIA8233_REG_TYPE_16BIT : 0) | /* format */ (runtime->channels > 1 ? VIA8233_REG_TYPE_STEREO : 0) | /* stereo */ -(0x * runtime->rate)/(48000/16) | /* rate */ +// (0x * runtime->rate)/(48000/16) | /* rate */ +0xf | 0xff00,/* STOP index is never reached */ port + VIA_REG_OFFSET_STOP_IDX); Please point me to the documentation in which such questions are described. 8235 detected as via8233C by alsa. But my kernel 2.4.20 has correct pci ID for via8235. May be this important. I will try to help you with development, but i need appropriate documentation. 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] via8235 swaped channels
Dear Takashi Iwai, Thursday, January 16, 2003, 12:21:42 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 = (1<<0) | (2<<4) | (5<<8) | (3<<12) | (4<<16); break; >> < case 6: slots = (1<<0) | (2<<4) | (5<<8) | (6<<12) | (3<<16) | (4<<20); >break; >> --- >> > //case 5: slots = (1<<0) | (2<<4) | (5<<8) | (3<<12) | (4<<16); break; >> > //case 6: slots = (1<<0) | (2<<4) | (5<<8) | (6<<12) | (3<<16) | (4<<20); >break; >> > case 5: slots = (1<<0) | (2<<4) | (3<<8) | (4<<12) | (5<<16); break; >> > case 6: slots = (1<<0) | (2<<4) | (3<<8) | (4<<12) | (5<<16) | (6<<20); >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? >> It will be nice to have a small prog for channel position testing in different >> playback modes, because now i know no 5.1ch source other then video player. >> In general multichannel playback has good quality now (with rc6 sound was >> cracking). Can you point me to a 5.1ch test audio file where recorded signals for single channel in known order ? I can easily understand where center channel is playing, but understanding where is Sub playing much more difficult task. You need big Stardestroyer for it =) 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] [Survey] headphone <-> master volume swap -- whichcodec chip?
I took a look at the Intel AC97 2.2 specs. It seems that the behaviour described here is a AC97 2.2 recommendation. take a look at 1 & 2 of 5.2.1. Pieter AC `97 Component Specification Revision 2.2 September 2000 5.2 LINE_OUT and AUX_OUT AC `97 audio Codecs support two independently controlled stereo outputs: 1. The master output, labeled LINE_OUT, uses pins 35, 36 for L and R (48 pin QFP package) and is controlled by the Master Volume Register 02h. No changes have been made to LINE_OUT definitions. 2. A second output, originally defined as HP_OUT, uses pins 39, 40, and 41 for L, Common, and R (48-pin QFP package) was re-defined as LNLVL_OUT for AC `97 2.1, and is controlled by optional volume Register 04h. In addition to the HP and LNLVL definitions, 4-channel Codecs typically utilize pins 39 and 41 for the additional (i.e. L & R Surround) outputs. 5.2.1 AUX_OUT Options As identified in the previous section, there are three common uses for AC `97's second output. AC `97 2.2 addresses all three uses by renaming the second output as AUX_OUT, Register 04h as Aux Out Volume, and the pins as AUX_OUT_L, AUX_OUT_C, and AUX_OUT_R. Driver developers should be aware that the AC `97 AUX_OUT may be implemented in one of three ways: 1.True line level out.Support for a true consumer equipment-compatible (10 k\Omega ) line level output that does not change with master volume settings. Either fixed or fixable via the independent volume controls in Register 04h, the output level provides a 1V RMS (2.8 V peak-to-peak) output level for a 0 dB gain PCM output stream. When implemented this way, AUX_OUT is equivalent to AC `97 2.1's LNLVL_OUT definitions. 2.Headphone out. AUX_OUT can be implemented to support integrated headphone amplifier with 32 \Omega drive capability and independent volume control via Register 04h. When implemented this way, AUX_OUT is equivalent to AC `97 1.03 original HP_OUT definitions 3. 4-Channel out. In Codecs that support 4-channel operation, AUX_OUT can be implemented to support the additional (i.e. L&R Surround) outputs. When implemented this way, AUX_OUT will be referred to 4CH_OUT. In 4CH_OUT implementations, L and R Surround output is controlled via Surround Volume Register 38h, not Aux Out Volume 04h, and powered down via the PRJ (SDAC) bit in Register 2Ah. AUX_OUT defaults to be LNLVL_OUT unless HP_OUT or 4CH_OUT support is detected. Unless the specific Codec configuration is indicated via INF file, driver writers should use the following methods for detecting a specialized Codec with HP_OUT or 4CH_OUT capabilities: * HP_OUT capability can be detected via Reset/ID Register 00h, ID bit 4 and the Aux Out Volume Register 04h default value reads "8000h" (i.e. implemented). ID4 is no longer used to indicate LNLVL support. * 4CH output capability can be detected via the Extended Audio ID Register 28h, SDAC ID bit 7, and a Surround Volume Register 38h default of "8080h" (i.e. implemented). HP and LNLVL implementations of AUX_OUT external output are powered down via bit PR6 in Register 26h. -- Takashi Iwai wrote: >At Fri, 24 Jan 2003 12:16:00 +0100 (CET), >Jaroslav wrote: > > >>On Fri, 24 Jan 2003, Takashi Iwai wrote: >> >> >> >>>Hi all, >>> >>>there have been bug-reports regarding to the swapping of headphone >>>and master volumes. >>>i'd like to ask you to check which AC97 codec chip is used on which >>>board (or laptop) if you have such a problem. if this happens only on >>>a certain chip model, we can add a quirk for that. >>> >>> >>Takashi, this quirk can be done only by detection of subvendor and >>subsystem from the PCI ID space. >> >> > >yeah, the lspci output is on the query list. > > > >>It's absolutely irrelevant which AC97 >>chip is used. >> >> > >really? i believe this happens only on certain ac97 chips. >for example, ALC202 spec says that ALC202A uses the headphone volume >as the "true line out" volume. so, apparently, some ac97 chips >"recommend" this behavior. let's see... > > > >>Vendor might wire codec in any way. Also, some codecs may >>swap line-out / headphone out via registers. >> >> > >this is a different case, imo. >the problem is that we have no chance to detect/switch them, either >manually or automatically. > >a general solution would be to add an ac97 control switch to swap >them. then the accssed registers are exchanged internally according >to this control. > >but it isn't bad to know which chips and which machines have this >problem, so that we can add quirks to turn on this switch >automatically. > > >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/li
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 24 January 2003 10:12, Takashi Iwai wrote: > > Ok, log output attached, 3 files with loads of gibberish ;). Same > > behavior btw. > thanks. sigh, this chip is really weird. > perhaps in the last patch, the recoverd pointer overtook the actual > pointer and got the driver confused. > take 6: the calculation of recovered pointer is changed. > and the register value of CURRPTR is shown as reference. > if it's more acculate, we can refer to it instead... > as usual, debug messages appear by enabling DEBUG_POITNER. Same deal as before, another 3 files filled with debug output. Good luck. :) - -- Regards, Tais M. Hansen OSD -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iQIVAwUBPjE0ZIIvLOJqwYc4AQLLFg/+NmqJA1HIeSmt6ukM/aw9v8n3fwLpK61k eGdakXrtZpao+T5EJG9aDsRoCJ6I5qRzw7s8KPFxx0AHLbDNMohLegTTxTB/KltT IFxRTW6JiAxwcRoR/nX/rFTZGEogXx8lTLIFALx8KD7jv/nudC0jWwFYeYKG9ky1 Q7zkbmdfcsivp2j7PUJVFGVQvYRYbrXvbaGD3BIfa7zPHWAaBK2tHWUZZ2TJFXT3 ZKoKtPnlzgxFXF9YP//OqE/Y5Qjjvs1SCk9hR4jL1yKmr9VeSCOySh+c8gAFOFaj hLICqz4fbtFkLurRk4B/puu8q/R4ftvC+z2cSUtvdLrVONzgYBwhsPibqKiI1hv5 wd6auUmMTxwar95iuiRNKdHPTId9FOZY0jEEJi4njOjZmUKSaZqa5g53OQ8rf63W GeupoL9DoGtewOpf4uvR6hvq5QjO2MGO0VyY5752LFyk7hIX1ryEvsuOsChMhOvl Akh+JVYXNSU+lgcnQCnrB45a9bH2MIIc0WnT8dlBi2o1oiyZTbp99n2GIt6y0ey4 L/ECWRoK0Wrd4yesPwNnl6S3AmmWKmZc8WurdDQcc5clOwTyZwXR67BSjXFTxTb8 oP6Q6zLMfFxcFReR1HCXWLbQGaw4oJbLuUh6zkGLnTxmizCc7uGZGnDpA/O6gWSq fsT3lXLYi60= =eiiU -END PGP SIGNATURE- alsa-aplay-test6.txt.gz Description: GNU Zip compressed data alsa-artsd-test6.txt.gz Description: GNU Zip compressed data alsa-ogg123-test6.txt.gz Description: GNU Zip compressed data
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
At Fri, 24 Jan 2003 13:41:06 +0100, Tais M. Hansen <[EMAIL PROTECTED]> wrote: > > [1 ] > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Friday 24 January 2003 10:12, Takashi Iwai wrote: > > > Ok, log output attached, 3 files with loads of gibberish ;). Same > > > behavior btw. > > thanks. sigh, this chip is really weird. > > perhaps in the last patch, the recoverd pointer overtook the actual > > pointer and got the driver confused. > > take 6: the calculation of recovered pointer is changed. > > and the register value of CURRPTR is shown as reference. > > if it's more acculate, we can refer to it instead... > > as usual, debug messages appear by enabling DEBUG_POITNER. > > Same deal as before, another 3 files filled with debug output. Good luck. :) it seems that we need to use CURRPTR always on your chip. i guess this depends on the board, how reliable IDX register is. if the attached new patch works, i'll add a module option to enable this behavior. good luck for you, too :) Takashi via-pointer-test7.dif Description: Binary data
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 24 January 2003 14:30, Takashi Iwai wrote: > > Same deal as before, another 3 files filled with debug output. Good luck. > > :) > it seems that we need to use CURRPTR always on your chip. > i guess this depends on the board, how reliable IDX register is. Need any specific info about the board? Chip? I saw some talks about the ALC650 chip in another thread on this list and alsamixer claims I've got such a chip. > if the attached new patch works, i'll add a module option to enable > this behavior. > good luck for you, too :) Thanks. Maybe we should exchange good luck more often. Seems like you worked some magic here. :) Ogg123 now plays but there's a lot of pops, clicks and stuttering. Log output were produced in both syslog and debug. Attached as allways. Aplay played as always. I think I heard pops here and there but it wasn't much. Log output from debug attached. Artsd started as supposed to with a single pop. Noatun seemed to play without any noticeable weirdness. No pops etc. Log output from debug attached. - -- Regards, Tais M. Hansen OSD -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iQIVAwUBPjFJwIIvLOJqwYc4AQJUkRAAjIJ66U1Fb2HDWHQcqRh0BnAIJKZaIki3 ky+IkXkJ32YqznaiO88Cv6GlRJjJAfES8IyRrUZB8WT0LA79mKGSQyoS5xoMK6MW KsqPPHf/h1o3QCKa/rY8OH0oPUzD5PvfGqU1Iyk3uUTjtaQYm+4B/V7wpQjfnRbb 5sumdqo8oWchgzoKqeY17bdPE7lAMxYoWeRglIPMI6N1I/iyJNAONnfHNMFVH1FE uZQ3EKipd7qMw8RZHA2+C29xTU3rK4aMqRMqsBHHNBXMzNsNIRuGenSYQAynHeCY U0UzPBirqZKCOWEJuBWjhEWhAk1CCnBb1vsM1MVEJ0e47RfIF9HL3kHK4Eiwk301 fHOIGR+x9iAO/21en8oVzEj6sNdWGMMPXV1U+byJbe/C6I7nRBQCBMZDdbw2/haU uvhzMoBihW7EwLoWlMFCXbseX3vcHf8lmSLyh39M+aK2FcMnYiFGE7gp0L84NS2Q mnh6b9CFDPlffGET9+DULqZqv/clYsqHLOtT7ECjLyb3zcm6rGw+pU3wKNPcRtpW GL0saHyIy1fhU6Z+LDSPYlcBDl0+AtjeGhNTG44UmrfW92SM1jJb0f52rRe0zelq hih9SE6meCIHYjBk9/LcCYYAdBW9sybBPqjr+ywskbNrLH87TrfYftpUWXAq1sar einpLW5cIcw= =K4LD -END PGP SIGNATURE- alsa-aplay-test7.txt.gz Description: GNU Zip compressed data alsa-artsd-test7.txt.gz Description: GNU Zip compressed data alsa-ogg123-test7.txt.gz Description: GNU Zip compressed data
[Alsa-devel] Re: [Alsa-user] No sound on Extigy
At Fri, 24 Jan 2003 00:16:25 -0500, Jean-Marc Valin wrote: > > [1 ] > > 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? please show me the kernel debug messages when you tried 44100 2ch samples! 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?
Hi, At Fri, 24 Jan 2003 13:41:29 +0100, Pieter Palmers wrote: > > I took a look at the Intel AC97 2.2 specs. It seems that the behaviour > described here is a AC97 2.2 recommendation. take a look at 1 & 2 of 5.2.1. thanks! > 5.2.1 AUX_OUT Options > As identified in the previous section, there are three common uses for > AC `97's second output. AC `97 2.2 addresses all three uses by > renaming the second output as AUX_OUT, Register 04h as Aux Out Volume, > and the pins as AUX_OUT_L, AUX_OUT_C, and AUX_OUT_R. > > Driver developers should be aware that the AC `97 AUX_OUT may be > implemented in one of three ways: > > 1.True line level out.Support for a true consumer > equipment-compatible (10 k\Omega ) line level output that does not > change with master volume settings. Either fixed or fixable via the > independent volume controls in Register 04h, the output level provides a > 1V RMS (2.8 V peak-to-peak) output level for a 0 dB gain PCM output > stream. When implemented this way, AUX_OUT is equivalent to AC `97 2.1's > LNLVL_OUT definitions. > > 2.Headphone out. AUX_OUT can be implemented to support integrated > headphone amplifier with 32 \Omega drive capability and independent > volume control via Register 04h. When implemented this way, AUX_OUT is > equivalent to AC `97 1.03 original HP_OUT definitions > > 3. 4-Channel out. In Codecs that support 4-channel operation, > AUX_OUT can be implemented to support the additional (i.e. L&R > Surround) outputs. When implemented this way, AUX_OUT will be referred > to 4CH_OUT. In 4CH_OUT implementations, L and R Surround output is > controlled via Surround Volume Register 38h, not Aux Out Volume 04h, > and powered down via the PRJ (SDAC) bit in Register 2Ah. > > AUX_OUT defaults to be LNLVL_OUT unless HP_OUT or 4CH_OUT support is > detected. hmm, then we need to implement the controls for the register 0x04 even if RESET/ID4 is 0..? currently, we build them only when RESET/ID4 is detected. but i've not known which chip has LNLVL without RESET/ID4. needs to check the spec for each chip. confusingly, there are ac97 chips which sets RESET/ID4 but uses AUX_OUT as LNLVL, such as ALC200, ALC201A or ALC202A. and on these chips, we have the problem as $SUBJECT states. furthremore, ALC201/2 uses it as HP_OUT, even though they have the same id as ALC201/2A! in this case, we need to check PCI subdev ID... 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] Santa Cruz (cs46xx) stopped working after 1-21-03
Hi! My Turtle Beach Santa Cruz card is not working with current CVS code. I downloaded several CVS snapshots and was able to trace the problem to changes that happened between the 2003-01-21.tar.bz2 and 2003-01-22.tar.bz2 snapshots (probably in cs46xx_lib.c). So, if I want to use my Santa Cruz I need to use the cs46xx driver from the 2003-01-21 snapshot. In 2003-01-22 and later, I see this message when I load the cs46xx modules: ALSA ../../alsa-kernel/pci/cs46xx/cs46xx_lib.c:3326: cs46xx: cs46xx_setup_eapd_slot() - no secondary codec configured With 2003-01-21 and before I don't see it. If anyone needs help to troubleshoot this please let me know. I'll be happy to try any patches or provide more information. Cheers, Eloy.- --- 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 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 --- 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] [Survey] headphone <-> master volume swap -- which codec chip?
Hi all, there have been bug-reports regarding to the swapping of headphone and master volumes. i'd like to ask you to check which AC97 codec chip is used on which board (or laptop) if you have such a problem. if this happens only on a certain chip model, we can add a quirk for that. please check the following and send to alsa-devel ML or to me. 1. ALSA driver version 2. lspci -v (for the soundchip only) 3. lspci -n (for the soundchip only) 4. output of /proc/asound/cards 5. output of /proc/asound/card0/ac97#0 6. output of /proc/asound/card0/ac97#0regs thanks in advance. 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
[Alsa-devel] cs46xx: failure waiting for FIFO command to complete
I am getting this message when I load the cs46xx module: ALSA ../../alsa-kernel/pci/cs46xx/cs46xx_lib.c:468: cs46xx: failure waiting for FIFO command to complete I think it does not happen when I boot the machine, i.e. the first time the card is initialized. It seems to happen only after the card has been initialized and I stop ALSA and then start it again (unload and reload modules.) It seems pretty harmless because everything works just fine, but I wonder if anyone knows the reason fot the message. I searched the mailing list archives and didn't find anything relevant. Cheers, Eloy.- --- 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 15:12:13 +0100, Tais M. Hansen <[EMAIL PROTECTED]> wrote: > > On Friday 24 January 2003 14:30, Takashi Iwai wrote: > > > Same deal as before, another 3 files filled with debug output. Good luck. > > > :) > > it seems that we need to use CURRPTR always on your chip. > > i guess this depends on the board, how reliable IDX register is. > > Need any specific info about the board? Chip? I saw some talks about the > ALC650 chip in another thread on this list and alsamixer claims I've got such > a chip. most likely it has nothing to do with ALC650. but lspci -v and lspci -n (for the chip) might be helpful for the later development. > > > if the attached new patch works, i'll add a module option to enable > > this behavior. > > good luck for you, too :) > > Thanks. Maybe we should exchange good luck more often. Seems like you worked > some magic here. :) now comes the patch of the week: now you'll have possibility to change the behavior of the driver via a module option idx_detect. idx_detect=0 : the default, won't work for you. idx_detect=1 : like test7. perhaps not perfect. idx_detect=2 : use the interrupt pointer only. the resolution will be in the size of periods. this should work. idx_detect=3 : like test7 but don't evaluate the counter. might be be finer than idx_detect=2 but might be inaccurate in some cases. if the debug output is only 'elapsed only', it's ok. have fun :) Takashi via-pointer-test8.dif Description: Binary data
Re: [Alsa-devel] [Survey] headphone <-> master volume swap -- which codec chip?
At Fri, 24 Jan 2003 15:41:12 +0100, I wrote: > > hmm, then we need to implement the controls for the register 0x04 even > if RESET/ID4 is 0..? currently, we build them only when RESET/ID4 is > detected. but i've not known which chip has LNLVL without RESET/ID4. > needs to check the spec for each chip. also, we need to think of a new control name for LNLVL (true line out). "True Line Out Playback"? it sounds too techincal... 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] via8235 swaped channels
At Thu, 23 Jan 2003 23:29:56 +0300, Anton Worshevsky wrote: > > Dear Takashi Iwai, > > Thursday, January 16, 2003, 12:21:42 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 = (1<<0) | (2<<4) | (5<<8) | (3<<12) | (4<<16); break; > >> < case 6: slots = (1<<0) | (2<<4) | (5<<8) | (6<<12) | (3<<16) | (4<<20); >break; > >> --- > >> > //case 5: slots = (1<<0) | (2<<4) | (5<<8) | (3<<12) | (4<<16); break; > >> > //case 6: slots = (1<<0) | (2<<4) | (5<<8) | (6<<12) | (3<<16) | (4<<20); >break; > >> > case 5: slots = (1<<0) | (2<<4) | (3<<8) | (4<<12) | (5<<16); break; > >> > case 6: slots = (1<<0) | (2<<4) | (3<<8) | (4<<12) | (5<<16) | (6<<20); >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? the switch above is irrelevant to this behavior. sorry for confusion. but there is another register bits, and i fixed it on the cvs. please update your alsa-kernel tree via cvs and give a try. > >> It will be nice to have a small prog for channel position testing in different > >> playback modes, because now i know no 5.1ch source other then video player. > >> In general multichannel playback has good quality now (with rc6 sound was > >> cracking). > > Can you point me to a 5.1ch test audio file where recorded signals for single > channel in known order ? > I can easily understand where center channel is playing, but understanding where > is Sub playing much more difficult task. You need big Stardestroyer for it =) well, i'm usually testing with a wav file decoded from an AC3 demo sound. the best way would be to create a file containing completely different samples (e.g. different songs) per channel... 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 24 January 2003 16:45, Takashi Iwai wrote: > > Need any specific info about the board? Chip? I saw some talks about the > > ALC650 chip in another thread on this list and alsamixer claims I've got > > such a chip. > most likely it has nothing to do with ALC650. > but lspci -v and lspci -n (for the chip) might be helpful for the > later development. $ lspci -s 00:11.5 -v 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio Controller (rev 40) Subsystem: Micro-star International Co Ltd: Unknown device 4720 Flags: medium devsel, IRQ 9 I/O ports at e800 [size=256] Capabilities: [c0] Power Management version 2 $ lspci -s 00:11.5 -n 00:11.5 Class 0401: 1106:3059 (rev 40) > now comes the patch of the week: > now you'll have possibility to change the behavior of the driver via a > module option idx_detect. > idx_detect=0 : the default, won't work for you. And it didn't. > idx_detect=1 : like test7. perhaps not perfect. No sound, so you're right. > idx_detect=2 : use the interrupt pointer only. the resolution will be >in the size of periods. this should work. Maybe. But it didn't. Seems to go a little too fast playing. No sound at all. > idx_detect=3 : like test7 but don't evaluate the counter. >might be be finer than idx_detect=2 but might be >inaccurate in some cases. This one killed my system the first time. Nice blinking keyboard leds. :) Second run it runs speeds through the file. No sound at all. I've attached log output from all idx'es, though only tested with ogg123. - -- Regards, Tais M. Hansen OSD -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iQIVAwUBPjFsa4IvLOJqwYc4AQL4Mw//ZCPhB71mnpTZmYxBGa0yym0j2FAfGPSy 4H2gAry+jpe9wDEOddijFaSdx/mYj04ST/4Vl+cNbPaV1kldMdrqWrU3Fx0vfIqE FRC5SapuNiykdI1kMVIDotiEWU5MEhZG2UB5TwhDkSwwI3lPKfJDUsax79KCfIz/ m/8m7j0j9K0gtmDZhmD8v2TEpiiT1mk927BpqcZVI8lI3F0Ya0ggD3rI+rB+TJXQ CMgZqO74TDVA2LoWPRGHVK/VPvvVEJmr2/5+TW9Y7E5zCJx1O1PsKGcXsv1P8Pw4 gRtLwJHxFhtgn59o8L2pJI+giy27ZpX8EJ+kj917r3S/XbXE62Hr/zWQBZN5HqMF 4YfWHukX3/+5yOkzfB257VXXYk6giHDiXyxXspw0nFbTZLwKuBNCRPxQZvrO1UQ/ TmFfLW6qvq8bMreO6q7xC7N+AWIpCXf1LkqEPZsjVozSBMKahWBSTIIpBGQalUGS pBPo3gVDIKXVJT9NCUufBcmYuyImehscO2aICL1ojEsNO7zqWtkmKyGNEt3m/yA1 yhWbHABwsY029UU7SnOQpcaps0xEtF5Nl/XjljTT7dMJwV4Nep26DNW1c+Dmt+si D1q7oWgmke6tqFXpXG3T/7vrWQMP50vag+Nf1whl3Zz31qkyqHFA1qlvcEyxFXuS zU5qKaolsfk= =lsXG -END PGP SIGNATURE- --- 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 Friday 24 January 2003 16:45, Takashi Iwai wrote: > have fun :) And here're the attached files...! ;) - -- Regards, Tais M. Hansen OSD -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iQIVAwUBPjFs9oIvLOJqwYc4AQJaSg/+P9KCNRSqPMYVpi5DI7BafqTiYXi6zGtY QMER59LquEljx1zLg+5WyURVEZfkJK37AM8HPpfcn3WsotfITKId8zdtbCFHPBPf G3bTvG9tD5WdIDaUmp/i6/tIABVZwhETBdpvrHhKv2L/mUv70QhpY55oDkRdDLVQ pxDhE3ILbTgMTPgYLpRSLXaTuHzO6xersRu0IYrxZY2psauFf/SIVBl7KuIpMFKm c97KGl0SLMtKv20QaFcu0lmiZzmB4RRd7acIGYUI3dgduixJdAlpD+evPkwIJcAT YEJDI7+Mj0Q6EmJHsvj43U8IBXIml9qWoZB6vR+TtugAndL/6fWwz325TxqKOg8Z KTaU3ac+vDIr9B/paHaBOlCPSm8ZIpQlPb5geDvQW8GTDogzfLwvbXCrZHe2i+mv +E/KD3XK0rPT8y68iOzpL2mirsfFCKvc+oTwKQgqdeR1juyahMQsk9tMjzVKitox 5OBjZW3RoCGGvp1Df1pmKk4Y3Igahv4L9gv6IqtlLpwSCikyR8uss+hijaXDPCzn nOYQFWa/Ml6uJiYBI0cGzR5CEANXci0CWYOHc69iYYG2K7YbmZXasmQ+aTRubcJq TzubdkRE+Wo+Lt2Ie8b/0q1hW4b8VB8TMF1jZvIYghjC4udGXnEsuej1yajvb0LD fuhp9XS5BPs= =Xekl -END PGP SIGNATURE- alsa-ogg123-test8-idx0.txt.gz Description: GNU Zip compressed data alsa-ogg123-test8-idx1.txt.gz Description: GNU Zip compressed data alsa-ogg123-test8-idx2.txt.gz Description: GNU Zip compressed data alsa-ogg123-test8-idx3.txt.gz Description: GNU Zip compressed data
Re: [Alsa-devel] Re: [Alsa-user] Upgrade problems -addendum
At Fri, 24 Jan 2003 17:40:09 +0100, Tais M. Hansen <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Friday 24 January 2003 16:45, Takashi Iwai wrote: > > > Need any specific info about the board? Chip? I saw some talks about the > > > ALC650 chip in another thread on this list and alsamixer claims I've got > > > such a chip. > > most likely it has nothing to do with ALC650. > > but lspci -v and lspci -n (for the chip) might be helpful for the > > later development. > > $ lspci -s 00:11.5 -v > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio > Controller (rev 40) > Subsystem: Micro-star International Co Ltd: Unknown device 4720 > Flags: medium devsel, IRQ 9 > I/O ports at e800 [size=256] > Capabilities: [c0] Power Management version 2 > > $ lspci -s 00:11.5 -n > 00:11.5 Class 0401: 1106:3059 (rev 40) sorry, i need the output of "lspci -nv". > > > now comes the patch of the week: > > now you'll have possibility to change the behavior of the driver via a > > module option idx_detect. > > idx_detect=0 : the default, won't work for you. > > And it didn't. > > > > idx_detect=1 : like test7. perhaps not perfect. > > No sound, so you're right. hmm, it should produce some sounds. > > idx_detect=2 : use the interrupt pointer only. the resolution will be > >in the size of periods. this should work. > > Maybe. But it didn't. Seems to go a little too fast playing. No sound at all. no sound? on all applications? then it can be another bug in the different place, which was got in during the last rewrite... 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] gnome-volume-control
*sorry for the resend...I meant to send this to the devel list
originally...*
I messed up my gnome-volume-control somehow through multiple attempts at
compiling and installing ALSA. Now, I get an error saying bad key or
directory name OSS-Tri Tech...
I have an Ensoniq 1371 for a sound card and I have looked in ~/.gconf but I
didn't find the problem. I've tried removing the %gconf.xml file but I must
not be getting the right one...can someone help me fix this??
thx
-bryanw
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/vol": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/pcm": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/speaker": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/line": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/mic": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/cd": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/igain": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/line1": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/phin": `(' is an invalid
character in key/directory names
Bad key or directory name:
"/apps/gnome-volume-control/OSS-TriTech_(3)-1/video": `(' is an invalid
character in key/directory names
---
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 11:06:09 +0100, I wrote: > > please check the following and send to alsa-devel ML or to me. > > 1. ALSA driver version > 2. lspci -v (for the soundchip only) > 3. lspci -n (for the soundchip only) correction: please run wiht -v option here (otherwise no sub-id will be shown). lspci -nv thanks, 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] MPU401 broken in CVS
Hi, I think that there might be some header file changes to commit in CVS too. Chris gcc -D__KERNEL__ -DMODULE=1 -I/home/chris/Programs/alsa/alsa-driver/include -I/home/chris/linux-2.4.20/include -O2 -mpreferred-stack-boundary=2 -march=i686 -D__SMP__ -DCONFIG_SMP -DLINUX -Wall -Wstrict-prototypes -fomit-frame-pointer -pipe -DALSA_BUILD -DEXPORT_SYMTAB -c mpu401_uart.c In file included from mpu401_uart.c:1: ../../alsa-kernel/drivers/mpu401/mpu401_uart.c: In function `snd_mpu401_uart_output_trigger': ../../alsa-kernel/drivers/mpu401/mpu401_uart.c:373: structure has no member named `mpu_output_lock' __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- 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 Friday 24 January 2003 18:08, Takashi Iwai wrote: > sorry, i need the output of "lspci -nv". $ lspci -s 00:11.5 -nv 00:11.5 Class 0401: 1106:3059 (rev 40) Subsystem: 1462:4720 Flags: medium devsel, IRQ 9 I/O ports at e800 [size=256] Capabilities: [c0] Power Management version 2 > > > 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. > > > idx_detect=2 : use the interrupt pointer only. the resolution will be > > >in the size of periods. this should work. > > Maybe. But it didn't. Seems to go a little too fast playing. No sound at > > all. > no sound? > on all applications? Well, I'd like to try, but now that my system froze on 1 and 3, I wouldn't dare. :) > then it can be another bug in the different place, which was got in > during the last rewrite... Sounds possible. If only I had more insight on audio hardware programming I'd might be able to be more helpful. - -- Regards, Tais M. Hansen OSD -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iQIVAwUBPjGvHoIvLOJqwYc4AQLkeBAAmC5cKCyCd7D3HoCfNSvd7DbtmppUtHV2 /6axRVxaJG+BTJ4fRiyZGzDJYywhvmgIpy6AlM81hNMwSWTXtx9AbyB7GKtBepTW qRUl/dB2E7oKmWvWNCL4h+wdyFeQqIqs5NG7QaOXtUaeQAJaacqmLrY22kmyx9ek 37hUBuWoJcX/VpGfvojhbOvoIspnMszgBiFOINHXE3cKi2y7YNyJp2LhDbeDVjhu Oy/oL4OIAAgB7OTFGFvlT2/w3zSiYs2ctuz5Rt9yHeMSZ4tb4nInI3epSlpWxZQr fCkTmcjD3bea30OMkjlK7B6AkNudPIG/qXIhl1gZrhYFBctCISDdJLxtR/P21U3C J7J6JiPhdTfBSgiglQBcngtWHL873ZiWHnmdrD5b+9n0ocylzKO92kEXIhUB1q52 aXtl5KRojnsPx7jnB6x7EYIc5A7DJMKkVdxXQT2cUxGhvSwkV3C1kGnwVm4V0s6S to22WbFpah3b8Ywfk+CInZGOc/zPDc61gLpf/Oo7Hv3zsCry4rd6JFM366I/jDlW 8s52bA4JKM1ch0kOB5IhC7iwVUOXYutwqDDJH5eq5WISWviU1WEuJefcxSmu7Hpt RqUEwEq+WQKHSWSpN9h/68EBpqkIiRXoFTfzSedKh34XYpYkr4IXtosorrIPh5VP RNsVE8j6cDI= =BSFL -END PGP SIGNATURE- --- 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
