On 2002.09.24 18:08 Peter Heatwole wrote:
>
>
>Booyah! Just got digital out working properly on my Santa Cruz, and
> it
> sounds great. I just needed to unmute "EGPIO In" and "IEC 958 Output".
My apologies, I was rushed for a meeting and had to fire that e-mail
off
in a hurry. (Not
>I suppose so. I just leave an MP3 playing in XMMS, and restart it
> after
> making a change (though this isn't required for all changes; I'm just
> cautious).
>I _think_ you modify each pin using the "EGPIO On/Off" to turn each
> pin
> on and off, and select the different pins using "EG
Hi all,
We are working with a cm8738 which is built into the
motherboard. We could not find the data sheets for the chipset. If
someone could direct us to the data sheets of cm8738 it will be great
else one doubt that we have about the card is -
when exactly does the card raise the interr
On 2002.09.24 18:45 Weijia Yang wrote:
> Thanks for the tip--everything compiles fine now. Now, how exactly do I
> go about testing these EGPIO settings? I see several EGPIO options in
> alsamixer--do I just adjust these and find something that works? Thanks
I suppose so. I just leave an M
>
>You probably just stuck a define in cs46xx_lib.c. Append the
> following into alsa-driver/pci/cs46xx/Makefile, to the end of the
> EXTRA_FLAGS line:
>
> -DCONFIG_SND_CS46XX_DEBUG_GPIO=1
>
>
> HTH,
> -- Peter Heatwole
> "Murphy was just a well known pessimist."
>
>
Thanks for the ti
On 2002.09.24 14:16 Benny Sjostrand wrote:
Booyah! Just got digital out working properly on my Santa Cruz, and
it
sounds great. I just needed to unmute "EGPIO In" and "IEC 958 Output".
Thanks again Benny,
-- Peter Heatwole
"Murphy was just a well known pessimist."
On 2002.09.24 17:10 Weijia Yang wrote:
> I am attempting to use the debug code, but after defining I get the
> following errors during compile:
[snip]
You probably just stuck a define in cs46xx_lib.c. Append the
following into alsa-driver/pci/cs46xx/Makefile, to the end of the
EXTRA_FLAGS
On 2002.09.24 14:16 Benny Sjostrand wrote:
> Finally, so far I know the Santa Cruz is yet another card where we dont
> have technical specifications. It's possible that there is any GPIO or
> whatever kind of logic that controls "something" that makes the sound
> better.
> Not having a Santa C
Benny Sjostrand wrote:>> Benny--
>
>
> Finally, so far I know the Santa Cruz is yet another card where we dont
> have technical specifications. It's possible that there is any GPIO or
> whatever kind of logic that controls "something" that makes the sound
> better.
> Not having a Santa Cruz
I'm trying to compile alsa 0.9rc3 on a Powerbook G4 DVI against
2.4.20-pre7 + benh patches, I get an error:
../alsa-kernel/ppc/burgundy.c:314: warning: (near initialization for `snd_pmac_b
urgundy_mixers[1]')
../alsa-kernel/ppc/burgundy.c:314: incompatible types in initialization
../alsa-kernel/p
>Takashi Iwai wrote
>the patch looks good except for the module options for spdif.
>since ac97_codec is a generic module, it's better to avoid
>such device specific options. isn't it detectable?
If the Yamaha YMF753 spec provided a way to autodetect which pin was being used for
S/PDIF ouput, I'
Hi,
OK, here's the first attempt to resolve some of those FIXMEs:
- Remove dependency on OSS emulation (trivial)
- Use udelay() in busy-waiting loops, remove HZ references
- Fix breakage in MIDI mixer control
- Minor whitespace issues
I have compiled the driver (hand-patching the Makefiles to g
hw_params:
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 4096
buffer_size: 32768
tick_time: 1
info:
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: emu10k1
name: EMU10K1
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 3
> Benny--
> Where exactly do I set this "external_amp" option? I see a
> 'External Amplifier Power Down' in amixer, but only option is muting,
> which turns sound off completely. Also, several other people have
> also reported the "flat" sounds, as well as cpu usage spikes when
> initiati
Takashi Iwai wrote:
>
> At Sat, 21 Sep 2002 15:02:42 +0200,
> Benny Sjostrand wrote:
> >
> > >
> > >
> > >Sep 20 17:32:48 JOHN-ANDREWS kernel: ALSA
> > >../../alsa-kernel/pci/cs46xx/cs46xx_lib.c:767: BUG? (cpcm->pcm_channel)
> > >(called from d087abc1)
> > >Sep 20 17:32:48 JOHN-ANDREWS kernel: AL
Benny Sjostrand wrote:
>> I am testing out the cs46xx experimental DSP drivers on the 9/22 cvs
>> build on a TB Santa Cruz. The drivers work fine except for the fact
>> that all sound is "flat"--almost no base at all. This is in comparison
>> to the original cs46xx drivers that come with rc3. T
> I am testing out the cs46xx experimental DSP drivers on the 9/22 cvs
> build on a TB Santa Cruz. The drivers work fine except for the fact
> that all sound is "flat"--almost no base at all. This is in comparison
> to the original cs46xx drivers that come with rc3. The sound quality
> differe
Thanks Paul. I am not sure how I was able to get the
data on channel 0 and 1 with the beta6, but to save
all of us from any more time on this matter, I am
going to have my application just look at channels 16
and 17. Thanks again for all you help.
--- Paul Davis <[EMAIL PROTECTED]> wrote:
> >O
Patrick Shirkey wrote:
> Takashi Iwai wrote:
>
>> the resolution of usb-audio device is 1ms. this value is fixed.
>> thus you need to adjust the period size according to the sample rate
>> if you want to achieve the real-time response with a small period
>> size.
>>
>> that means:
>> - the sampl
At Mon, 23 Sep 2002 12:45:15 -0700 (PDT),
Shane Walton wrote:
>
> When tyring to use beta6, ..., beta9, I get an error
> in the device open() call that states an unknown/bad
> ioctl command. The beta6 worked well with the 2.2.19
> kernel. I am wondering if this is a problem when used
> with a 2
>Otherwise, if I will be using the alsa-lib plugin for
>striding the channels, would I be better off using the
if you ask for non-interleaved data, there is no striding going
on. the hardware is not interleaved.
>Intel Performance Primitives (IPP) libraries to do the
>channel striding? I do wan
On Tue, 24 Sep 2002, Takashi Iwai wrote:
> Hi,
>
> (I removed alsa-users from Cc)
>
> At Fri, 20 Sep 2002 10:56:01 +0200,
> Gerard Janssen wrote:
> >
> > I tried to find the spdif output port addresses by changing the register
> > addresses of EXTOUT_TOSLINK_L/R in emu10k1.h to all 16 possible
At Tue, 24 Sep 2002 08:42:03 -0700 (PDT),
Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
>
> On Tue, 24 Sep 2002, Takashi Iwai wrote:
> > At Mon, 23 Sep 2002 21:14:36 -0700 (PDT),
> > Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mon, 23 Sep 2002, Clemens Ladisch wrote:
> > > > In theory, s
Hi,
(I removed alsa-users from Cc)
At Fri, 20 Sep 2002 10:56:01 +0200,
Gerard Janssen wrote:
>
> I tried to find the spdif output port addresses by changing the register
> addresses of EXTOUT_TOSLINK_L/R in emu10k1.h to all 16 possible output
> address pairs between (00 - 1f). To do this, I rem
At Mon, 23 Sep 2002 21:14:36 -0700 (PDT),
Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
>
> On Mon, 23 Sep 2002, Clemens Ladisch wrote:
> > Fedor G. Pikus wrote:
> > > On Fri, 20 Sep 2002, Clemens Ladisch wrote:
> > >
> > > > case EXPIRED:
> > > > snd_printd("capture read error (D
On Tue, 24 Sep 2002, Takashi Iwai wrote:
> At Mon, 23 Sep 2002 21:28:09 -0700,
> David Shust wrote:
> >
> > I've written a patches for the 0.9.0rc2 and 0.9.0rc3 ac97-codec
> > driver in order to support the Yamaha YMF753. This chip is used in
> > the Toshiba Satellite 5000. Support is provided f
> are you trying to record a s/pdif signal, or an ADAT
> signal?
The input on ADAT1 (in) is an optical line connected
directly to a DAT Recorder/Player. So maybe I am
confused, isn't this specific optical input connection
an ADAT signal? Or should I be setting the optical
input as s/pdif? If t
At Mon, 23 Sep 2002 19:18:40 +0300 (EEST),
Panagiotis Papadakos wrote:
>
> For two weeks now, compiling the ALSA from CVS, I get distorted sound
> through XMMS with the ALSA plugin and also from mpg123 with OSS. Does
> anybody has the same problem?
does the problem still appear on the latest cvs
At Mon, 23 Sep 2002 21:28:09 -0700,
David Shust wrote:
>
> I've written a patches for the 0.9.0rc2 and 0.9.0rc3 ac97-codec
> driver in order to support the Yamaha YMF753. This chip is used in
> the Toshiba Satellite 5000. Support is provided for S/PDIF output,
> enhanced (wide) stereo, and the no
At Mon, 23 Sep 2002 20:43:19 +0100 (BST),
Chris Rankin wrote:
>
> > > > another point: doesn't the busy-loop in
> > > > host_read/write_ctrl_unsafe
> > > > need udelay() or something to produce a certain
> > > > delay length?
> > > > otherwise the timeout is very dependent on a
> > > > machine.
David Shust wrote:
> I would be delighted to have this merged with the ALSA driver,
> provided that my copyright notice is left intact. It is only written
> to the console if and when the YMF753 is actually detected: ALSA AC'97
> patch for Yamaha YMF753 (c) David Shust <[EMAIL PROTECTED]>
>
> Is t
31 matches
Mail list logo
