Clemens Ladisch wrote:
Patrick Shirkey wrote:
Using the latest usb-audio code from cvs I get a kernel panic when
loading the drivers.
I'm running kernel-2.2.21 with gcc-2.95.4
Unable to handle kernel paging request at virtual address 28302e63
EIP:0010:[]Tainted: PF
e08e7060 __insmod_snd-us
Patrick Shirkey wrote:
> >>Using the latest usb-audio code from cvs I get a kernel panic when
> >>loading the drivers.
> >>
> >>I'm running kernel-2.2.21 with gcc-2.95.4
>
> Unable to handle kernel paging request at virtual address 28302e63
> EIP:0010:[]Tainted: PF
>
> e08e7060 __insmod_snd
Clemens Ladisch wrote:
Patrick Shirkey wrote:
Using the latest usb-audio code from cvs I get a kernel panic when
loading the drivers.
I'm running kernel-2.2.21 with gcc-2.95.4
Works fine with my 2.2.19(?).
ALSA 1.0.4 fixed some horrible bugs in the USB compatibility code for
2.2.x kernels.
Wher
Patrick Shirkey wrote:
> Using the latest usb-audio code from cvs I get a kernel panic when
> loading the drivers.
>
> I'm running kernel-2.2.21 with gcc-2.95.4
Works fine with my 2.2.19(?).
ALSA 1.0.4 fixed some horrible bugs in the USB compatibility code for
2.2.x kernels.
Where exactly does t
Using the latest usb-audio code from cvs I get a kernel panic when
loading the drivers. After that I cannot unload the modules and have to
reboot if I want to try again.
This doesn't happen with the hdsp driver or cmipci driver which I also use.
I'm running kernel-2.2.21 with gcc-2.95.4
--
Pat
Clemens Ladisch wrote:
> Jaroslav Kysela wrote:
>
> > I don't know much about USB 2.0,
>
> Not too much differences for the driver.
Well, I should have read the specification before saying such things.
The format of synchronization information has changed, too; it's not
10.14 bits but 12.13 packe
Karsten Wiese wrote:
> We can also vary the exact USB frame time.
> With UHCI 1.1 USB Hosts there is the SOF Register.
> ...
> It really works here already with the us428: The trick is:
> We first make the USB-Frame longer until we capture 1 Sample Frame more 45
> (for 44100). then the USB-Frame i
Karsten Wiese wrote:
We can also vary the exact USB frame time.
With UHCI 1.1 USB Hosts there is the SOF Register.
It is setable from 0 to 255, the default being 127.
Using this SOF-Register, we can set the actual USB Frame Rate from
((12000 - 127) / 12000)ms to ((12000 + 128) / 12000)ms. That is
We can also vary the exact USB frame time.
With UHCI 1.1 USB Hosts there is the SOF Register.
It is setable from 0 to 255, the default being 127.
Using this SOF-Register, we can set the actual USB Frame Rate from
((12000 - 127) / 12000)ms to ((12000 + 128) / 12000)ms. That is about -/+ 1%:
More t
Takashi Iwai wrote:
> Clemens Ladisch wrote:
> >
> > > I don't know much about USB 2.0,
> >
> > Not too much differences for the driver. The main difference is that
> > there are now 8000 microframes per second. I have written a patch
> > (see below) and am about to test it.
>
> is there any "rea
At Wed, 10 Mar 2004 09:26:27 +0100 (MET),
Clemens Ladisch wrote:
>
> > I don't know much about USB 2.0,
>
> Not too much differences for the driver. The main difference is that
> there are now 8000 microframes per second. I have written a patch
> (see below) and am about to test it.
is there a
At Wed, 10 Mar 2004 10:08:26 +0100 (CET),
Jaroslav wrote:
>
> On Wed, 10 Mar 2004, Clemens Ladisch wrote:
>
> > Jaroslav Kysela wrote:
> >
> > > On Tue, 9 Mar 2004, Takashi Iwai wrote:
> > >
> > > > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > > > perfectly suitab
Jaroslav Kysela wrote:
> On Wed, 10 Mar 2004, Clemens Ladisch wrote:
>
> > Conceptually, USB devices have variable-sized periods. The question
> > is whether we actually want to allow this in the API. Probably not.
>
> What this does mean? I though that the period size is specified with time
> (
On Wed, 10 Mar 2004, Clemens Ladisch wrote:
> Jaroslav Kysela wrote:
>
> > On Tue, 9 Mar 2004, Takashi Iwai wrote:
> >
> > > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > > perfectly suitable for the devices like USB audio.
> >
> > Unfortunately I don't see a better
Jaroslav Kysela wrote:
> On Tue, 9 Mar 2004, Takashi Iwai wrote:
>
> > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > perfectly suitable for the devices like USB audio.
>
> Unfortunately I don't see a better model.
Conceptually, USB devices have variable-sized period
On Tue, 9 Mar 2004, Takashi Iwai wrote:
> BTW, the USB audio is another headache. the current ALSA PCM model isn't
> perfectly suitable for the devices like USB audio.
Unfortunately I don't see a better model. We have already clear handshake,
but USB 1.1 devices, and maybe the Linux core USB code
Takashi Iwai wrote:
no, it has nothing to do with the latency but oopsen / lock-up.
the problem exists only at stopping the streams. if the everything is
ok, it's not a big issue. but, when the device runs with small
latency, which may result in xrun often, has the higher probability to
hit thi
At Thu, 20 Nov 2003 23:33:52 +0900,
Patrick Shirkey wrote:
>
> Takashi Iwai wrote:
> >
> > the current code is surely buggy, because it issues sync unlink
> > inside the spinlocked context. it's problematic on 2.6 kernel or SMP
> > system, and may result in kernel oops. i added async_unlink mod
Hello list,
I'm new here so hi, and sorry if I missed out on things discussed earlier.
I subscribed to this list because I've been having lost of problems with
the USB driver over the past half year (similar to the stuff mentioned in
this thread). So much so, that I am prepared to dive into the co
At Thu, 20 Nov 2003 15:28:25 -0500,
Karim Yaghmour wrote:
>
>
> Takashi Iwai wrote:
> > it'd be better to clean unlink_mask in the complete callback for the
> > case you use async unlink mode (see below).
> > and, the check of active_mask should be done in prepare callback, not
> > in the trigger
Takashi Iwai wrote:
it'd be better to clean unlink_mask in the complete callback for the
case you use async unlink mode (see below).
and, the check of active_mask should be done in prepare callback, not
in the trigger callback. the trigger callback must be as short as
possible. we can put deactiv
Niklas Werner wrote:
hmmm, the submit_urb-error is gone, but random lockups and
usb-device-disconnect until reboot have come... (bitkeeper-2.6 from just
one hour ago...) with your function.
Interesting. I haven't seen any of these.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded
Takashi Iwai wrote:
the current code is surely buggy, because it issues sync unlink
inside the spinlocked context. it's problematic on 2.6 kernel or SMP
system, and may result in kernel oops. i added async_unlink module
option to change the behavior in the new version.
but it's still disabled as
At Thu, 20 Nov 2003 00:50:03 -0500,
Karim Yaghmour wrote:
>
>
> Well, it seems that I'm going to have to answer my own self ... :)
>
> The following is what I've been able to find using additional tracing
> info. Also there's a fix for usbaudio.c.
>
> Basically, it's as I said before: the usbau
At Thu, 20 Nov 2003 11:04:52 +0100,
Niklas Werner wrote:
>
> Karim Yaghmour wrote:
>
> >
> > Well, it seems that I'm going to have to answer my own self ... :)
>
> Yes, usb-audio seems to be a bit forgotten... (Takashi, those
> mplayer-plughw-segfaults still persist, even on x86 and even with k
Karim Yaghmour wrote:
Well, it seems that I'm going to have to answer my own self ... :)
Yes, usb-audio seems to be a bit forgotten... (Takashi, those
mplayer-plughw-segfaults still persist, even on x86 and even with kernel
2.4 (current cvs of drivers/lib, of course)
The following is what I've
Well, it seems that I'm going to have to answer my own self ... :)
The following is what I've been able to find using additional tracing
info. Also there's a fix for usbaudio.c.
Basically, it's as I said before: the usbaudio driver uses URBs
without even checking if they're in use or not. Surprisi
I've been trying to fix some problems I'm getting with the USB audio
driver.
Basically, I get these types of messages over and over accompanied
by some audio glitches:
ALSA usbaudio.c:688: cannot submit datapipe for urb 0, err = -6
usb-uhci.c: ENXIO 00038200, flags 2, urb cf74f5c0, burb cf74f5c0
I'
At Fri, 31 Oct 2003 09:23:02 +0100,
Niklas Werner wrote:
>
> Am Donnerstag, 30. Oktober 2003 20:46 wurde geschrieben:
> > At Thu, 30 Oct 2003 13:42:14 +0100,
> >
>
> > hmm, really weird.
> >
> > meanwhile, i rewrote snd_pcm_linear_convert() without goto trick.
> > could you try the attached patch
Am Donnerstag, 30. Oktober 2003 20:46 wurde geschrieben:
> At Thu, 30 Oct 2003 13:42:14 +0100,
>
> hmm, really weird.
>
> meanwhile, i rewrote snd_pcm_linear_convert() without goto trick.
> could you try the attached patch?
... you don't really want to know...
Program received signal SIGSEGV, Se
At Thu, 30 Oct 2003 13:42:14 +0100,
Niklas Werner wrote:
>
> Am Donnerstag, 30. Oktober 2003 13:17 schrieb Takashi Iwai:
> > At Wed, 29 Oct 2003 23:26:07 +0100,
> >
> > Niklas Werner wrote:
> > > Am Mittwoch, 29. Oktober 2003 19:24 wurde geschrieben:
> > > > At Tue, 28 Oct 2003 20:18:35 +0100,
> >
Am Donnerstag, 30. Oktober 2003 13:17 schrieb Takashi Iwai:
> At Wed, 29 Oct 2003 23:26:07 +0100,
>
> Niklas Werner wrote:
> > Am Mittwoch, 29. Oktober 2003 19:24 wurde geschrieben:
> > > At Tue, 28 Oct 2003 20:18:35 +0100,
> > >
> > >
> > > hmm, it seems that a wrong label is used. the label shou
At Wed, 29 Oct 2003 23:26:07 +0100,
Niklas Werner wrote:
>
> Am Mittwoch, 29. Oktober 2003 19:24 wurde geschrieben:
> > At Tue, 28 Oct 2003 20:18:35 +0100,
> >
> >
> > hmm, it seems that a wrong label is used. the label should be
> > conv_xx12_xx21 (= conv_labels[35]). something is really broken
Am Mittwoch, 29. Oktober 2003 19:24 wurde geschrieben:
> At Tue, 28 Oct 2003 20:18:35 +0100,
>
>
> hmm, it seems that a wrong label is used. the label should be
> conv_xx12_xx21 (= conv_labels[35]). something is really broken.
>
> could you check stepwise the loop there?
>
still checking (any ti
At Tue, 28 Oct 2003 20:18:35 +0100,
Niklas Werner wrote:
>
> Here we go again,
>
> Am Dienstag, 28. Oktober 2003 19:25 schrieb Takashi Iwai:
>
> > > hmm, then something wrong in the converter routine...
> > > needs to take a deeper look.
> >
> > i found a bug regarding the plugin but it must be
Here we go again,
Am Dienstag, 28. Oktober 2003 19:25 schrieb Takashi Iwai:
> > hmm, then something wrong in the converter routine...
> > needs to take a deeper look.
>
> i found a bug regarding the plugin but it must be another bug from the
> above problem.
>
> segfault is a bit puzzling. could
At Tue, 28 Oct 2003 14:28:57 +0100,
I wrote:
>
> > gdb:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 16384 (LWP 28218)]
> > 0x0fd47d64 in snd_pcm_linear_convert () from /usr/lib/libasound.so.2
> > (gdb) bt
> > #0 0x0fd47d64 in snd_pcm_linear_convert () fr
At Tue, 28 Oct 2003 13:42:15 +0100,
Niklas Werner wrote:
>
> [1 ]
> Am Dienstag, 28. Oktober 2003 13:13 wurde geschrieben:
> > At Tue, 28 Oct 2003 12:48:17 +0100,
> >
> > Niklas Werner wrote:
> > > Am Dienstag, 28. Oktober 2003 12:10 schrieb Takashi Iwai:
> > > > > No, I don't think it is.
> > >
Am Dienstag, 28. Oktober 2003 13:13 wurde geschrieben:
> At Tue, 28 Oct 2003 12:48:17 +0100,
>
> Niklas Werner wrote:
> > Am Dienstag, 28. Oktober 2003 12:10 schrieb Takashi Iwai:
> > > > No, I don't think it is.
> > > > I get similar problems with my emi 2|6 and alsaplayer, mplayer,
> > > > xmms,
At Tue, 28 Oct 2003 12:48:17 +0100,
Niklas Werner wrote:
>
> Am Dienstag, 28. Oktober 2003 12:10 schrieb Takashi Iwai:
> >
> > > No, I don't think it is.
> > > I get similar problems with my emi 2|6 and alsaplayer, mplayer, xmms,
> > > ...
> >
> > did you use plughw instead of hw in all cases?
>
Am Dienstag, 28. Oktober 2003 12:10 schrieb Takashi Iwai:
>
> > No, I don't think it is.
> > I get similar problems with my emi 2|6 and alsaplayer, mplayer, xmms,
> > ...
>
> did you use plughw instead of hw in all cases?
> otherwise they won't work always.
plughw doesn't work at all!
> mplayer h
At Tue, 28 Oct 2003 11:41:07 +0100,
Niklas Werner wrote:
>
> Am Dienstag, 28. Oktober 2003 11:11 schrieb Takashi Iwai:
> > At Mon, 27 Oct 2003 20:53:08 +0100,
> >
> > Antonio Willy Malara wrote:
> > > On 2003.10.27 19:16, Takashi Iwai wrote:
> > > > > /* FIXME: correct endianess and sign? */
Am Dienstag, 28. Oktober 2003 11:11 schrieb Takashi Iwai:
> At Mon, 27 Oct 2003 20:53:08 +0100,
>
> Antonio Willy Malara wrote:
> > On 2003.10.27 19:16, Takashi Iwai wrote:
> > > > /* FIXME: correct endianess and sign? */
> > >
> > > could you give more information:
> > > which program, whi
At Mon, 27 Oct 2003 20:53:08 +0100,
Antonio Willy Malara wrote:
>
> On 2003.10.27 19:16, Takashi Iwai wrote:
> > > /* FIXME: correct endianess and sign? */
> > could you give more information:
> > which program, which device and what format doesn't it work?
>
> the system is a powermac, the dev
On 2003.10.27 19:16, Takashi Iwai wrote:
>/* FIXME: correct endianess and sign? */
could you give more information:
which program, which device and what format doesn't it work?
the system is a powermac, the device is a Griffin iMic, the app is jack
version 0.80, the output is:
Sorry. The audi
At Mon, 27 Oct 2003 19:03:00 +0100,
Antonio Willy Malara wrote:
>
> When is it planned the fix of the usb-audio driver for big endian
> machines? I'm refferring particularly to that:
>
> /* FIXME: correct endianess and sign? */
>
> (in function parse_audio_format_i_type (); at line 1990 i
When is it planned the fix of the usb-audio driver for big endian
machines? I'm refferring particularly to that:
/* FIXME: correct endianess and sign? */
(in function parse_audio_format_i_type (); at line 1990 in file alsa-
kernel/usb/usbaudio.c version 1.67)
Willy
hello list,
i'm crossposting this problem because it looks like it may be something more
suited to the developers list. i'm having some problems getting sound to
play through my emagic emi 2|6 usb soundcard. i've set up my internal sound
card on slot 0, and the emi on slot 1. modules are loade
At Sun, 06 Jul 2003 14:21:52 +0100,
James Courtier-Dutton wrote:
>
> I have a question regarding the callbacks in the usbaudio.c driver.
> The callback is defined as: -
>
> /*
> * complete callback from data urb
> */
> static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
>
>
I have a question regarding the callbacks in the usbaudio.c driver.
The callback is defined as: -
/*
* complete callback from data urb
*/
static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
The callback is set up with: -
u->urb->complete = snd_usb_complete_callback(snd_complete_ur
> At Sun, 22 Jun 2003 20:45:09 -0700,
> [EMAIL PROTECTED] wrote:
> >
> >
> > Am attempting to get linux-2.5.72 + snd-usb-audio happening.
> > Results have been poor. Machine is VIA C3, ALSA + jack working
> > fine with the built-in via audio. Tried various kernels,
> > real ugly failures with 2
> At Mon, 23 Jun 2003 23:54:46 -0700,
> [EMAIL PROTECTED] wrote:
> >
> > > At Sun, 22 Jun 2003 20:45:09 -0700,
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > >
> > > > Am attempting to get linux-2.5.72 + snd-usb-audio happening.
> > > please try the cvs version.
>
> Takashi
>
ALSA cvs + linux-
> At Mon, 23 Jun 2003 23:54:46 -0700,
> [EMAIL PROTECTED] wrote:
> >
> > > At Sun, 22 Jun 2003 20:45:09 -0700,
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > >
> > > > Am attempting to get linux-2.5.72 + snd-usb-audio happening.
> > > > Results have been poor. Machine is VIA C3, ALSA + jack workin
At Mon, 23 Jun 2003 23:54:46 -0700,
[EMAIL PROTECTED] wrote:
>
> > At Sun, 22 Jun 2003 20:45:09 -0700,
> > [EMAIL PROTECTED] wrote:
> > >
> > >
> > > Am attempting to get linux-2.5.72 + snd-usb-audio happening.
> > > Results have been poor. Machine is VIA C3, ALSA + jack working
> > > fine with
> At Sun, 22 Jun 2003 20:45:09 -0700,
> [EMAIL PROTECTED] wrote:
> >
> >
> > Am attempting to get linux-2.5.72 + snd-usb-audio happening.
> > Results have been poor. Machine is VIA C3, ALSA + jack working
> > fine with the built-in via audio. Tried various kernels,
> > real ugly failures with 2
At Sun, 22 Jun 2003 20:45:09 -0700,
[EMAIL PROTECTED] wrote:
>
>
> Am attempting to get linux-2.5.72 + snd-usb-audio happening.
> Results have been poor. Machine is VIA C3, ALSA + jack working
> fine with the built-in via audio. Tried various kernels,
> real ugly failures with 2.5.70, also have
Am attempting to get linux-2.5.72 + snd-usb-audio happening.
Results have been poor. Machine is VIA C3, ALSA + jack working
fine with the built-in via audio. Tried various kernels,
real ugly failures with 2.5.70, also have tried 2.5.72-mm2.
So far, this is the best I can do:
JACK compiled wit
Hi List!
I am just wondering whether anybody has a solution for following
(admittedly minor) bug:
When I cold-boot (doesn't matter whether PPC or Intel) with my emi 2|6
or reconnect the device the range of the mixer always is set to 0-50%
while using the full range in the hardware. So 50% mixe
iriXx <[EMAIL PROTECTED]> writes:
> just upgraded mandrake from 8.2 to 9.0
> and found out that it seems to have made my alsa all foobar :(
>
> i recompiled and reinstalled alsa 0.9.rc5 after upgrading... but i
> dont seem to be able to get it working.
> im running a quattro usb audio uni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi
just upgraded mandrake from 8.2 to 9.0
and found out that it seems to have made my alsa all foobar :(
i recompiled and reinstalled alsa 0.9.rc5 after upgrading... but i dont
seem to be able to get it working.
im running a quattro usb audio
Patrick Shirkey wrote:
I guess that ssm (and possibly JACK) has some mem leaks.
It seems I spoke too soon. I'm seeing memory leaks while using
alsaplayer or xmms. Alsaplayer connected via the alsa driver and xmms
through oss.
I'm going through about 1 MB/min :(
Is this an alsa issue or sho
Patrick Shirkey wrote:
I'm getting a lot of wierd sound quality bugs while using JACK. It seems
like the driver is storing the crappyness somewhere and each time I
access it the quality gets worse. Is it possible that the driver could
allow the data to linger and make things unstable?
I have b
I'm getting a lot of wierd sound quality bugs while using JACK. It seems
like the driver is storing the crappyness somewhere and each time I
access it the quality gets worse. Is it possible that the driver could
allow the data to linger and make things unstable?
I have been doing some testing t
I have done extensive testing now and can say that the jack quality is
exactly the same as the quality from accessing alsa directly with the
quattro.
Before the merge of the modules jack would not work at all but the sound
quality of the quattro was crisp and clean. Now jack has absolutely no
At Thu, 3 Oct 2002 23:02:07 -0700 (PDT),
Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
>
> Could you explay me what does it do? It sets "crate" what used to be
> "runtile->rate" but then it does not do anything with crate?
it checks the requested rate value has been really set on the
interface. but
At Thu, 26 Sep 2002 12:42:32 -0700 (PDT),
Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
>
> This is the right interface and altset (I was capturing with -r 96000 -f
> S16_LE). Two more files from proc about this pcm:
> pcm0c/sub0/hw_params
> access: RW_INTERLEAVED
> format: S16_LE
> subformat: STD
>
At Thu, 26 Sep 2002 09:47:50 +0200 (METDST),
Clemens Ladisch wrote:
>
> Fedor G. Pikus wrote:
> > On Wed, 25 Sep 2002, Takashi Iwai wrote:
> > > At Tue, 24 Sep 2002 20:03:54 -0700 (PDT),
> > > Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > then the complete callback is called properl
Fedor G. Pikus wrote:
> On Wed, 25 Sep 2002, Takashi Iwai wrote:
> > At Tue, 24 Sep 2002 20:03:54 -0700 (PDT),
> > Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
> > >
> > > > then the complete callback is called properly but likely
> > > > snd_pcm_period_elapsed() is not called.
> > >
> > > That's rig
At Tue, 24 Sep 2002 20:03:54 -0700 (PDT),
Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
>
> > then the complete callback is called properly but likely
> > snd_pcm_period_elapsed() is not called.
>
> That's right, it's not called:
> for (i = 0; i < urb->number_of_packets; i++) {
> cp = (unsig
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
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
Fedor G. Pikus wrote:
> On Fri, 20 Sep 2002, Clemens Ladisch wrote:
>
> > case EXPIRED:
> > snd_printd("capture read error (DMA or IRQ trouble?)\n");
> > err = -EIO;
> >
> > Are you _really_ sure you have recompiled the entire alsa-driver package
> > with debug o
Fedor G. Pikus wrote:
> > Fedor G. Pikus wrote:
> > > > > > > arecord: pcm_read:1049: read error: Input/output error
> > >
> > > Still nothing in the log, even with --with-debug=full
>
> I built arecord and libasound with debug and went into it with gdb.
> I traced it to the function static snd_p
Fedor G. Pikus wrote:
> > > It happens with either S16_LE or S24_3LE if the rate is 96000.
> > > It does not happen right away, but after several seconds.
>
> With raw the file length is 0. With wav is was probably just the header,
> the length is right, 44.
So it doesn't record anything, and nee
Fedor G. Pikus wrote:
> On Mon, 16 Sep 2002, Clemens Ladisch wrote:
> > > arecord: pcm_read:1049: read error: Input/output error
> >
> > Anything in /var/log/mesages?
> > Does it happen with 24 bits, too?
> > Is the data in the file correct (as far as is has been recorded)?
>
> Nothing in the log
At Thu, 12 Sep 2002 23:19:30 -0700 (PDT),
Fedor G. Pikus <[EMAIL PROTECTED]> wrote:
>
> So yeah, S16_LE at 48000 is not there. But in rc3 it is there, and it works!
> So I don't think this is right, I should have -f dat.
could you update the cvs tree again and configure the driver with
--debug=d
At Fri, 13 Sep 2002 14:59:40 +0900,
Patrick Shirkey wrote:
>
> Takashi Iwai wrote:
> > At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> > Clemens Ladisch wrote:
> >
> The two PCM devices cannot be used at the same time anyway, so I think
> creating a quirk for interface 0 which says "ignor
Takashi Iwai wrote:
> At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> Clemens Ladisch wrote:
>
The two PCM devices cannot be used at the same time anyway, so I think
creating a quirk for interface 0 which says "ignore this" could work.
Takashi, any comments?
>>>
>>>i think implementing
Takashi Iwai wrote:
> At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> Clemens Ladisch wrote:
>
The two PCM devices cannot be used at the same time anyway, so I think
creating a quirk for interface 0 which says "ignore this" could work.
Takashi, any comments?
>>>
>>>i think implementing
At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
Clemens Ladisch wrote:
>
> > > The two PCM devices cannot be used at the same time anyway, so I think
> > > creating a quirk for interface 0 which says "ignore this" could work.
> > > Takashi, any comments?
> >
> > i think implementing a semaphore (or
Takashi Iwai wrote:
> At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> Clemens Ladisch wrote:
>
The two PCM devices cannot be used at the same time anyway, so I think
creating a quirk for interface 0 which says "ignore this" could work.
Takashi, any comments?
>>>
>>>i think implementing
At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
Clemens Ladisch wrote:
>
> > > The two PCM devices cannot be used at the same time anyway, so I think
> > > creating a quirk for interface 0 which says "ignore this" could work.
> > > Takashi, any comments?
> >
> > i think implementing a semaphore (or
Takashi Iwai wrote:
> is there any good text-format tool for usb descriptors except for
> humanbeing?
The /proc/asound/card?... information of snd-usb-audio ;-)
Fedor, it would be interesting to see how much got parsed with uhci.
> > There are two PCM devices, but both use the same endpoints.
>
At Mon, 09 Sep 2002 19:46:21 +0200,
Clemens Ladisch wrote:
>
> Fedor G. Pikus wrote:
> > > > Why doesn't 48KHz work, and where are higher rates, where is 24bit
> > > > recording?
> > >
> > > These features should be available if the device has correct descriptors.
> > > Please post the output of
Fedor G. Pikus wrote:
> > > Why doesn't 48KHz work, and where are higher rates, where is 24bit
> > > recording?
> >
> > These features should be available if the device has correct descriptors.
> > Please post the output of lsusb.
>
> Wow, that's a long output. Here is is:
> ...
Let's make a nic
Hello!
The CVS version of ALSA doesn't compile on a 2.2.21 kernel. The error
messages (just the beginning, there are more) are:
In file included from usbaudio.c:2:
../alsa-kernel/usb/usbaudio.c:1234: warning: `struct usb_device_id'
declared inside parameter list
../alsa-kernel/usb/usbaudio.c:1
>>hmm, it's not so easy, since this will break also the assumption of
>>constant period "frames" by applications. if we introduce the
>>time-based period size, it won't work as compatible as older one,
>>e.g. jack wouldn't run properly if the period size changes
>>dynamically.
this isn't true, o
Takashi Iwai wrote:
>At Tue, 20 Aug 2002 13:34:03 +0200 (CEST),
>Tim Goetze wrote:
>>
>> Takashi Iwai wrote:
>>
>> >> With the current setup and cycle code for mmap'd IO (like Jack for
>> >> example does it), is it possible to use these devices at all?
>> >
>> >on 48kHz my usb speaker worked fi
At Tue, 20 Aug 2002 13:34:03 +0200 (CEST),
Tim Goetze wrote:
>
> Takashi Iwai wrote:
>
> >> With the current setup and cycle code for mmap'd IO (like Jack for
> >> example does it), is it possible to use these devices at all?
> >
> >on 48kHz my usb speaker worked fine with 1ms or 2ms period size
Takashi Iwai wrote:
>> With the current setup and cycle code for mmap'd IO (like Jack for
>> example does it), is it possible to use these devices at all?
>
>on 48kHz my usb speaker worked fine with 1ms or 2ms period size (not
>under high loads, though), since the frames per urb becomes integer i
At Tue, 20 Aug 2002 12:30:11 +0200 (CEST),
Tim Goetze wrote:
>
> Takashi Iwai wrote:
>
> >> How can we implement the latency-optimal behaviour with alsa-driver
> >> framework?
> >> Can we implement something like a snd_1ms_elapsed() routine (called from
> >> USB-interrupt), which in turn trigger
Takashi Iwai wrote:
>> How can we implement the latency-optimal behaviour with alsa-driver
>> framework?
>> Can we implement something like a snd_1ms_elapsed() routine (called from
>> USB-interrupt), which in turn triggers a waiting app with the available
>> period size (which would be 44 or 45 f
At Mon, 19 Aug 2002 15:17:51 +0200,
Karsten Wiese wrote:
>
> Hi,
>
> usb iso transfers happen every 1ms (USB1.1) ( or at multiples of 125µs for
> USB2.0).
> this timing is fixed and leads to a variable amount of frames available at
> interrupt.
> looking at 44100Hz on USB 1.1, we receive/send 44
Hi,
usb iso transfers happen every 1ms (USB1.1) ( or at multiples of 125µs for
USB2.0).
this timing is fixed and leads to a variable amount of frames available at
interrupt.
looking at 44100Hz on USB 1.1, we receive/send 44 frames on 9 of 10
USB-interrupts and 45 frames on 1 of 10
USB-interrupts.
Hi,
I'm having a few problems getting the Extigy to work using
alsa-driver-0.9.0rc3. When I use aplay to play a .au file, it cuts off
the end of the file and gives the xrun message shown below.
I'm running Debian 3.0 using the 2.4.19-xfs kernel.
Here are a few symptoms I've found so far:
lsus
At Fri, 05 Jul 2002 23:24:06 +0900,
Patrick Shirkey wrote:
>
> tapio laxström wrote:
> > Hi!
> >
> > Seems like USB Audio driver doesn't want to be on /dev/mixer0 ;)
>
> Possibly your card doesn't have mixer properties. The quattro doesn't. I
> don't know exactly how to get round that with xmm
tapio laxström wrote:
> Hi!
>
> Seems like USB Audio driver doesn't want to be on /dev/mixer0 ;)
Possibly your card doesn't have mixer properties. The quattro doesn't. I
don't know exactly how to get round that with xmms though. You could try
the native alsa plugin available from their site.
At Tue, 4 Jun 2002 10:37:22 +0200,
Niklas Werner wrote:
>
> Hi All!
>
> the silent reader strikes again...
>
> Thanks a lot for usb-audio-support in alsa!
>
> Just to let you know:
> it works fine with the emagic emi2|6-interface by using the
> oss-firmware-loader from http://www.vtoy.fi/~tap
Hi All!
the silent reader strikes again...
Thanks a lot for usb-audio-support in alsa!
Just to let you know:
it works fine with the emagic emi2|6-interface by using the
oss-firmware-loader from http://www.vtoy.fi/~tapio/emi26.html and
rmmod-ing "audio" afterwards!
I tried it on a powerbook p
Are there any plans to support USB devices in ALSA?
Namely the Creative Labs Extigy.
Or does this have nothing to do with ALSA at all?
Thanks.
-- R:
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists
100 matches
Mail list logo
