On Mon, 2003-12-08 at 13:04, Sergey Vlasov wrote:
> Most likely you need the dxs_support option instead of ac97_clock.
>
> With dxs_support=2 the sound should work fine, but the hardware mixing
> capability will be disabled. Then you can try dxs_support=1 or
> dxs_support=4.
>
> By default snd-
Hi, I'm having a problem with snd_mixer_selem_set_playback_volume_range().
It works ok, except that the values I read back (with
snd_mixer_selem_get_playback_volume()) does not seem to be scaled with the
new range until the volume is changed somehow. Both changing the volume
by calling snd_mixer
> Most likely you need the dxs_support option instead of ac97_clock.
>
> With dxs_support=2 the sound should work fine, but the hardware mixing
> capability will be disabled. Then you can try dxs_support=1 or
> dxs_support=4.
>
> By default snd-via82xx uses dxs_support=3 (except for certain known
On Mon, Dec 08, 2003 at 01:15:18PM +0100, p z wrote:
> Probably user has normal soundcard handled by ALSA and TV card
> (btaudio or saa7134) which provides only OSS drivers (warning - only
> recording - not playback). TV card is default /dev/dsp (can by
> changed by module option for btaudio,
On Mon, Dec 08, 2003 at 12:16:55PM -0800, Mark Knecht wrote:
> On Mon, 2003-12-08 at 01:05, Clemens Ladisch wrote:
> > This is a module option; instead of changing this line, you are
> > supposed to put the following line into modules.conf:
> >
> > options snd-via82xx ac97_clock=44100
> >
> > (
On Mon, 2003-12-08 at 01:05, Clemens Ladisch wrote:
> This is a module option; instead of changing this line, you are
> supposed to put the following line into modules.conf:
>
> options snd-via82xx ac97_clock=44100
>
> (or, if an options line for this module already exists, add it there)
>
>
On Mon, 8 Dec 2003 17:57:03 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
On Mon, 8 Dec 2003, Arve Knudsen wrote:
Wether its done via the control or pcm interface, it'd be good to have a
loose coupling between configuration and streams, so one could could
access
configuration space wi
>I don't agree. The control API (usually) is for things that don't affect
>the way data is transferred between the card the the computer.
it is *now*. i was just imagining a different conception of what it
could be used for.
> Sample
On Mon, 8 Dec 2003, Arve Knudsen wrote:
> Wether its done via the control or pcm interface, it'd be good to have a
> loose coupling between configuration and streams, so one could could access
> configuration space without locking a stream don't you think? I mean,
> with ASIO, from what I can see
On Mon, 2003-12-08 at 07:49, Clemens Ladisch wrote:
> Mark Knecht wrote:
> >BTW - how can I get a list of all possible module options for a given
> > card or device? Is there any way to find out about this without reading
> > the code?
>
> modinfo snd-via82xx
Cool. Thanks. I don't see explan
On Mon, 8 Dec 2003 16:19:36 +0100, Giuliano Pochini <[EMAIL PROTECTED]>
wrote:
On Sun, 07 Dec 2003 14:19:28 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
i personally am heading towards believing that we made a design
decision that was wrong here. i now tend to think that the PCM
interface should n
Mark Knecht wrote:
>BTW - how can I get a list of all possible module options for a given
> card or device? Is there any way to find out about this without reading
> the code?
modinfo snd-via82xx
or read alsa-kernel/Documentation/ALSA-Configuration.txt and
alsa-driver/INSTALL.
HTH
Clemens
On Mon, 2003-12-08 at 01:05, Clemens Ladisch wrote:
> [EMAIL PROTECTED] wrote:
> > Hi, I've got a motherboard with a builtin soundcard, proc/pci says:
> > VIA Technologies, Inc. VT8233/A/8235 AC97 Audio Controller (rev 80)
> > (The Mobo is a Gigabyte GA-7VAX, a VIA KT400 chipset with a VT8235)
> >
On Sun, 07 Dec 2003 14:19:28 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> i personally am heading towards believing that we made a design
> decision that was wrong here. i now tend to think that the PCM
> interface should not be involved with configuring the hardware at all,
> and that this shoul
deactivate_urbs didn't return the number of still-active URBs when not
unlinking asynchronously, which would prevent calling wait_clear_urbs
when some URBs actually are being unlinked asynchronously, so these
URBs would be freed while still in use.
I removed deactivate_urb's return value because
Index: alsa-driver/pci/Kconfig
===
RCS file: /cvsroot/alsa/alsa-driver/pci/Kconfig,v
retrieving revision 1.6
diff -u -r1.6 Kconfig
--- alsa-driver/pci/Kconfig 6 Oct 2003 14:01:01 - 1.6
+++ alsa-driver/pci/Kconfig 8 D
Hi,
Probably user has normal soundcard handled by ALSA and TV card
(btaudio or saa7134) which provides only OSS drivers (warning - only
recording - not playback). TV card is default /dev/dsp (can by
changed by module option for btaudio, saa7134). For BT87x users there
is alsa driver in ALSA 1.
Is there a reliable way to find out if /dev/dsp is being handled by
ALSA? I want to be able to detect this for diagnostics. (If /dev/dsp
is ALSA, the native alsa-lib code should have been used, and something
has gone wrong.) Currently, I'm checking for the existance of
/proc/asound/version, but
On Mon, 8 Dec 2003 12:39:25 +0100, Frank Barknecht <[EMAIL PROTECTED]>
wrote:
Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:
On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht <[EMAIL PROTECTED]>
wrote:
>Which reminds me to ask: how does Portaudio currently cope with
>user-defined, not en
Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:
> On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht <[EMAIL PROTECTED]>
> wrote:
> >Which reminds me to ask: how does Portaudio currently cope with
> >user-defined, not enumerable interfaces in ALSA?
> Only concrete hardware devices are cons
On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht <[EMAIL PROTECTED]>
wrote:
Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:
I'm one of the developers responsible for the ALSA implementation of a
cross
platform audio wrapper called PortAudio (www.portaudio.com), which
gathers
info about
Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:
> I'm one of the developers responsible for the ALSA implementation of a
> cross
> platform audio wrapper called PortAudio (www.portaudio.com), which gathers
> info about available devices during startup.
Which reminds me to ask: how does Por
[EMAIL PROTECTED] wrote:
> Hi, I've got a motherboard with a builtin soundcard, proc/pci says:
> VIA Technologies, Inc. VT8233/A/8235 AC97 Audio Controller (rev 80)
> (The Mobo is a Gigabyte GA-7VAX, a VIA KT400 chipset with a VT8235)
>
> and I find that (on Line 83 in alsa-kernel/pci/via82xx.c) th
23 matches
Mail list logo
