Its the same PCI ID, but insmod segfaults...
does the attched patch cure the segfault?
but it doesn't mean that your card will be supported by it :)
takashi - thanks for this patch. i didn't understand that
snd_hdsp_free() could be called when no hardware was detected. now i do :)
--p
At Fri, 29 Nov 2002 15:14:28 +0100,
I wrote:
Please, remove from your code any checks from ioctl(), poll(), read() /
write(). Then commit and I'll merge my tree with yours.
ok.
done. please merge your tree.
ciao,
Takashi
---
This
On Fri, 29 Nov 2002, Takashi Iwai wrote:
Hi,
the attached is my latest patch.
could you check it?
Let's go and make things more complicated (like in my tree on disc):
1) waiting for time when all disconnected applications have closed
all file descriptors is a bit problem, because no
At Fri, 29 Nov 2002 15:05:21 +0100 (CET),
Jaroslav wrote:
On Fri, 29 Nov 2002, Takashi Iwai wrote:
Hi,
the attached is my latest patch.
could you check it?
Let's go and make things more complicated (like in my tree on disc):
1) waiting for time when all disconnected
At Sun, 10 Nov 2002 02:32:11 -0800,
David Shust wrote:
My latest Yamaha YMF753 patch for alsa-driver-0.9.0rc5 is available at
www.shustring.com.
hi, the patch was applied to cvs with some modification.
could you check whther it works for you?
thanks!
Takashi
At Fri, 29 Nov 2002 12:40:48 +0100,
Rafal Dejewski wrote:
On Friday 29 November 2002 12:03, you wrote:
ok, the devices are there. i think it's a bug of the driver, which
assumes the order of devices from 1533 - 7101.
please try the patch attached (to cvs).
That did it! Cool!
ok,
On Friday 29 November 2002 12:03, you wrote:
ok, the devices are there. i think it's a bug of the driver, which
assumes the order of devices from 1533 - 7101.
please try the patch attached (to cvs).
That did it! Cool!
The oss emulation works great. I have some problems in mplayer and xmms
On Fri, 29 Nov 2002, Takashi Iwai wrote:
At Fri, 29 Nov 2002 10:39:22 +0100 (CET),
Jaroslav wrote:
On Fri, 29 Nov 2002, Takashi Iwai wrote:
At Fri, 29 Nov 2002 08:52:43 +0100 (MET),
Clemens Ladisch wrote:
Takashi Iwai wrote:
Martin Langer wrote:
usb hotplug
At Fri, 29 Nov 2002 12:24:50 +0100 (CET),
Jaroslav wrote:
On Fri, 29 Nov 2002, Takashi Iwai wrote:
At Fri, 29 Nov 2002 10:39:22 +0100 (CET),
Jaroslav wrote:
On Fri, 29 Nov 2002, Takashi Iwai wrote:
At Fri, 29 Nov 2002 08:52:43 +0100 (MET),
Clemens Ladisch wrote:
On Friday 29 November 2002 11:29, you wrote:
At Fri, 29 Nov 2002 11:19:40 +0100,
looking at the code, ali5451 driver access the following three pci
devices:
10b9:5451 ali5451 main chip
10b9:1533 pci southbridge, used for ac97 codec
10b9:7107 power management controller (which
At Fri, 29 Nov 2002 11:47:25 +0100,
Rafal Dejewski wrote:
On Friday 29 November 2002 11:29, you wrote:
At Fri, 29 Nov 2002 11:19:40 +0100,
looking at the code, ali5451 driver access the following three pci
devices:
10b9:5451 ali5451 main chip
10b9:1533 pci southbridge, used
At Fri, 29 Nov 2002 11:19:40 +0100,
Rafal Dejewski wrote:
On Friday 29 November 2002 11:12, you wrote:
At Fri, 29 Nov 2002 10:53:15 +0100,
ah, perhaps your chip has some different pci id?
please check lspci -n whether a device 10b9:7101 exists.
I think this is it! I should have
On Friday 29 November 2002 11:12, you wrote:
At Fri, 29 Nov 2002 10:53:15 +0100,
ah, perhaps your chip has some different pci id?
please check lspci -n whether a device 10b9:7101 exists.
I think this is it! I should have noticed!
Here is mine lspci -vvn for this device:
00:04.0 Class 0401:
At Fri, 29 Nov 2002 10:53:15 +0100,
Rafal Dejewski wrote:
PCI: Found IRQ 7 for device 00:04.0
resouces allocation ...
resouces allocated.
snd_device_new is called.
chip initializing ...
ALSA sound/pci/ali5451/ali5451.c:2159: ali create: chip init error.
it looks like the
At Fri, 29 Nov 2002 10:39:22 +0100 (CET),
Jaroslav wrote:
On Fri, 29 Nov 2002, Takashi Iwai wrote:
At Fri, 29 Nov 2002 08:52:43 +0100 (MET),
Clemens Ladisch wrote:
Takashi Iwai wrote:
Martin Langer wrote:
usb hotplug works perfect if my usbmidi client isn't aconnected to
On Thursday 28 November 2002 17:36, Takashi Iwai wrote:
Hi,
At Thu, 21 Nov 2002 12:29:59 +0100,
Rafal Dejewski wrote:
Hi,
I have HP vt6200 notebook. It has ALI5451 chip. I tried diffrent kernels
2.4.18, 2.4.19, 2.4.20rc1, 2.5.48 and alsa-driver 0.9rc4,rc5,rc6.
The standard kernel
On Fri, 29 Nov 2002, Takashi Iwai wrote:
At Fri, 29 Nov 2002 08:52:43 +0100 (MET),
Clemens Ladisch wrote:
Takashi Iwai wrote:
Martin Langer wrote:
usb hotplug works perfect if my usbmidi client isn't aconnected to another
midi client. But the aconnected usb midi device still
At Fri, 29 Nov 2002 08:52:43 +0100 (MET),
Clemens Ladisch wrote:
Takashi Iwai wrote:
Martin Langer wrote:
usb hotplug works perfect if my usbmidi client isn't aconnected to another
midi client. But the aconnected usb midi device still remains in the clients
list, after hotpluging
At Thu, 28 Nov 2002 21:47:11 -0500,
Boris Shingarov wrote:
Takashi,
make a patch for emu10k2 to make it work as emu10k1-compatible
Are you referring to the recent post from Garin on emu10k1-devel,
named Audigy 2 anomalies? As far as I understand, the guy is
talking about making
On Friday 29 November 2002 00.05, vanDongen-Gilcher wrote:
Out of curiosity,
What makes a card support mmap directly in general? And what would be
missing?
I'm sure I'll get corrected if I say something wrong here:
If the card itself can transfer its samples from its onboard buffer into
Takashi Iwai wrote:
Martin Langer wrote:
usb hotplug works perfect if my usbmidi client isn't aconnected to another
midi client. But the aconnected usb midi device still remains in the clients
list, after hotpluging out.
yep, when the connection exists, the connected devices (on both
Takashi,
make a patch for emu10k2 to make it work as emu10k1-compatible
Are you referring to the recent post from Garin on emu10k1-devel,
named Audigy 2 anomalies? As far as I understand, the guy is
talking about making Audigy2 behave like Audigy - not Audigy
vs. emu10k1 :-(
Out of curiosity,
What makes a card support mmap directly in general? And what would be
missing?
Gerard
Anders Torger said at Re: rme96 and mmap, bug?.r[2002/11/27 18:13]
The hardware does not support memory mapped I/O, so it is copied by the
CPU in the interrupt handler. Thus for that
At 12:06 25/11/02, you wrote:
On Sun, 24 Nov 2002, James Stafford wrote:
Has anyone started work on a driver for the VIA VT1724 (alias Envy24HT)?
The company I work for are planning to release a PC104+ card based on
this chipset (paired with the VT1616) in the very near future so I have
At Tue, 5 Nov 2002 20:33:16 +0100,
[EMAIL PROTECTED] wrote:
Hi,
I've been trying to get ALSA running on my Compaq Armada 3500 for quite a
while now. The soundchip is a es1869, which is supposed to be supported by
the es18xx driver. It only works 1 out of 10 times though - and I figured
On Thu, 2002-11-28 at 16:22, Justin Cormack wrote:
Thanks, this fixes the segfault, and adding the rev 0x64 in
snd_hdsp_create makes it work... It recognises the IO box as a digiface
which I think is ok (3x adat + midi + 2 * spdif). Playback works, and
the mixer is recognised - will test it
At Tue, 5 Nov 2002 12:18:40 +0200 (EET),
Pasi Kärkkäinen wrote:
On Mon, 4 Nov 2002, Takashi Iwai wrote:
At Sun, 3 Nov 2002 22:49:10 +0200 (EET),
Pasi Kärkkäinen wrote:
Hello!
Anyone working with SB Audigy driver to get hwac3 working?
unfortunately, it's not supported
On Thu, 2002-11-28 at 15:40, Takashi Iwai wrote:
all i need is the PCI ID from you. i've already spoken to RME about
the card, and the claim is that it will with the existing h-dsp
driver. the only thing that won't work are the RMS meters. the
existing driver, however, doesn't
At Thu, 28 Nov 2002 17:00:35 +0100 (MET),
Clemens Ladisch wrote:
Takashi Iwai wrote:
Clemens Ladisch wrote:
The snd_seq_midisynth_register_port() function already knows the name of
the rawmidi device, so there is no reason to invent another name for the
sequencer client.
the
Hi,
At Thu, 21 Nov 2002 12:29:59 +0100,
Rafal Dejewski wrote:
Hi,
I have HP vt6200 notebook. It has ALI5451 chip. I tried diffrent kernels
2.4.18, 2.4.19, 2.4.20rc1, 2.5.48 and alsa-driver 0.9rc4,rc5,rc6.
The standard kernel trident module works OK on all kernels but alsa driver
does not
At 24 Nov 2002 17:49:55 -0800,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I have an Nforce equipped Motherboard that has an SPDIF output. The
intel8x0 driver works great for the analog out, but no SPDIF. Is the
SPDIF supported?
at the last time i've tried, it didn't work.
above
Takashi Iwai wrote:
Clemens Ladisch wrote:
The snd_seq_midisynth_register_port() function already knows the name of
the rawmidi device, so there is no reason to invent another name for the
sequencer client.
the reason was that many rawmidi devices give the same name even if
there are
At Wed, 27 Nov 2002 10:46:53 +0100 (CET),
Jaroslav wrote:
On Wed, 27 Nov 2002, Bruce Paterson wrote:
Am I sending these queries about the operation of alsa through the API
to the right place ? I'm trying to use alsa for a real scientific
application and I'm starting to worry it simply
Hi,
At 26 Nov 2002 12:42:12 +0100,
Antonin ENFRUN wrote:
I'm using alsa-driver 0.9.0rc6 on an Asus A7V8X (via8235 southbridge and
ALC650 -ac97 compatible- codec).
PCM output is fine on the main analog channel, but SPDIF out is not
working for any FS != 48khz. Looking at the source, the
At Tue, 26 Nov 2002 22:43:35 +0100,
Andreas Mohr wrote:
On Mon, Nov 25, 2002 at 09:37:03AM -0800, [EMAIL PROTECTED]
wrote:
Message: 3
Date: Mon, 25 Nov 2002 11:40:38 +0900
From: Patrick Shirkey [EMAIL PROTECTED]
Organization: Boost Hardware
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
At 28 Nov 2002 14:39:41 +,
Justin Cormack wrote:
On Thu, 2002-11-28 at 13:42, Paul Davis wrote:
I have just got a couple of the new RME Hammerfall HDSP9652 cards, and
find that they are not supported by the snd-hdsp driver yet. The card is
basically the same hardware as the other hdsp
On Thu, Nov 28, 2002 at 02:39:41PM +, Justin Cormack wrote:
On Thu, 2002-11-28 at 13:42, Paul Davis wrote:
I have just got a couple of the new RME Hammerfall HDSP9652 cards, and
find that they are not supported by the snd-hdsp driver yet. The card is
basically the same hardware as the
At Thu, 28 Nov 2002 13:38:01 +0100 (MET),
Clemens Ladisch wrote:
The snd_seq_midisynth_register_port() function already knows the name of
the rawmidi device, so there is no reason to invent another name for the
sequencer client.
the reason was that many rawmidi devices give the same name
On Thu, 2002-11-28 at 13:42, Paul Davis wrote:
I have just got a couple of the new RME Hammerfall HDSP9652 cards, and
find that they are not supported by the snd-hdsp driver yet. The card is
basically the same hardware as the other hdsp cards but with the io
integrated on the card.
I would
its also worth noting that it too is not immune from missing xruns,
but there isn't anything we can do about kernel/driver code that
blocks interrupts for an entire buffer :(
I do not know how long an entire buffer is. I assume this will differ per
card, but how small could the worst-case
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On November 27, 2002 10:04 am, Paul Davis wrote:
its also worth noting that it too is not immune from missing xruns,
but there isn't anything we can do about kernel/driver code that
blocks interrupts for an entire buffer :(
I do not know how long
I have just got a couple of the new RME Hammerfall HDSP9652 cards, and
find that they are not supported by the snd-hdsp driver yet. The card is
basically the same hardware as the other hdsp cards but with the io
integrated on the card.
I would guess that it will need a different firmware and
actually, it can't. if the user space application is delayed for
precisely 1 buffer's worth of data, it will see the pointer at what
appears to the the right place and believe that no xrun has
occured. the only way around this is to provide either:
Well, but if you combine it with the current
The snd_seq_midisynth_register_port() function already knows the name of
the rawmidi device, so there is no reason to invent another name for the
sequencer client.
Index: alsa-kernel/core/seq/seq_midi.c
===
RCS file:
At Thu, 28 Nov 2002 01:27:02 +0100,
Martin Langer wrote:
Hi,
usb hotplug works perfect if my usbmidi client isn't aconnected to another
midi client. But the aconnected usb midi device still remains in the clients
list, after hotpluging out. The next hotplug in of my usb device needs an
Paul Davis wrote:
Am I sending these queries about the operation of alsa through the API
to the right place ? I'm trying to use alsa for a real scientific
application and I'm starting to worry it simply isn't ready yet.
the API is ready. the documentation is not. some of us have been using
Hi,
usb hotplug works perfect if my usbmidi client isn't aconnected to another
midi client. But the aconnected usb midi device still remains in the clients
list, after hotpluging out. The next hotplug in of my usb device needs an
aconnect -x before or I won't see my card in /proc/asound/cards
On Wed, 2002-11-27 at 17:21, Justin Cormack wrote:
I have just got a couple of the new RME Hammerfall HDSP9652 cards, and
find that they are not supported by the snd-hdsp driver yet. The card is
basically the same hardware as the other hdsp cards but with the io
integrated on the card.
On Wed, 27 Nov 2002, Paul Davis wrote:
i see this as more promising than the approach i think you are
thinking of. you can't avoid the context switching - they *have* to
happen so that the apps can run!! the question is *when* does it
happen ... in JACK, they are initiated in a chain when the
On Wed, 27 Nov 2002, Paul Davis wrote:
Please stop the complication of available/delay etc. Just the raw
pointer. Each application knows where its application pointer is, so
it can easily calculate delay/available and decide for itself whether
there was an overrun or not.
actually, it
On Wed, 27 Nov 2002, Paul Davis wrote:
Let's be totally clear about this. its not just that the callback
model is suitable - the mserver model will actually not work for
sample sync between applications. I have always been sure that the
I think this is the critical point. ALSA's smix/mserver
Hi
Please review the attached message. I was requested to post this message in the
alsa-devel group by the author. I would like to get my hoontech/staudio 7.1 sound
system working with linux and I'm very close. I still can't control the volume, and I
made the changes in the source code
On Wed, 27 Nov 2002, Alamy Liu wrote:
Hi All,
I am going to write a audio driver which connect to ARM based CPU
directly using I2C and L3.
From the developer's document. It seems the main structure are Card
Chipset.
In the Card layer, what kind of card driver should I implement ?
On Wed, 27 Nov 2002, tomasz motylewski wrote:
On Wed, 27 Nov 2002, Jaroslav Kysela wrote:
In my brain, there is also totaly different solution with the zero context
switching overhead - sharing the soundcard DMA buffer among more
applications. There is only one problem:
On Wed, 27 Nov 2002, Paul Davis wrote:
This is my personal preference. In this model the only service ALSA has to
supply are:
1. initial configuration/start/stop.
2. mmapable DMA buffer
3. fact and precise ioctl telling the current HW pointer in the buffer. If the
card is not queried each
I am currently taking the following approach: -
Always prepare 2 audio hardware periods of sample frames in advance
inside the user app.
1) snd_pcm_wait()
2) write()
3) prepare new sample frames, then go back to (1).
for lower latency, you'd do:
1) snd_pcm_wait()
2) prepare new sample frames
Paul Davis wrote:
I am currently taking the following approach: -
Always prepare 2 audio hardware periods of sample frames in advance
inside the user app.
1) snd_pcm_wait()
2) write()
3) prepare new sample frames, then go back to (1).
for lower latency, you'd do:
1) snd_pcm_wait()
2)
This is my personal preference. In this model the only service ALSA has to
supply are:
1. initial configuration/start/stop.
2. mmapable DMA buffer
3. fact and precise ioctl telling the current HW pointer in the buffer. If the
card is not queried each time, then the last period interrupt timestamp
Hi All,
I am going to write a audio driver which connect to ARM based CPU
directly using I2C and L3.
From the developer's document. It seems the main structure are Card
Chipset.
In the Card layer, what kind of card driver should I implement ?
A virtual-card ? (exp : i2c/i2c-pxa250.c and
Sorry, it's not as easy as you've described. It's not possible to invoke
any user code from the kernel code directly. There is a scheduler which is
informed that a task has been woken up. It depends on scheduler when the
task is really invoked. It's quite same as for the r/w model where the
tomasz motylewski wrote:
Please stop the complication of available/delay etc. Just the raw pointer.
Each application knows where its application pointer is, so it can easily
calculate delay/available and decide for itself whether there was an overrun or
not.
I use the delay() function.
I
Am I sending these queries about the operation of alsa through the API
to the right place ? I'm trying to use alsa for a real scientific
application and I'm starting to worry it simply isn't ready yet.
the API is ready. the documentation is not. some of us have been using
ALSA to develop
Ok, it's only simple example, that there are more solutions than Paul
suggests. I fully agree, that the callback model is suitable for the
perfect synchronization among more applications.
Let's be totally clear about this. its not just that the callback
model is suitable - the mserver model
I have read your comments below, and I would like to try to explain the
problems I am coming up against when writing a multi-media app.
I am not going to say that I know everything about kernel scheduling,
but for multi media applications, avoiding xruns is a major concern.
This becomes
On Wed, 27 Nov 2002, Jaroslav Kysela wrote:
In my brain, there is also totaly different solution with the zero context
switching overhead - sharing the soundcard DMA buffer among more
applications. There is only one problem: snd_pcm_rewind() implementation
This is my personal preference.
On Wed, 27 Nov 2002, Bruce Paterson wrote:
Am I sending these queries about the operation of alsa through the API
to the right place ? I'm trying to use alsa for a real scientific
application and I'm starting to worry it simply isn't ready yet.
I don't pretend to be a developer of alsa
On Wed, 27 Nov 2002, James Courtier-Dutton wrote:
Paul Davis wrote:
the APIs that are used to write almost all audio software code in
production these days all use a callback model.
Sorry for questioning this statement. Of course we all don't have any statisti
cal data
Alamy Liu wrote:
I would like to know if there is any Developer documentation for
ALSA 0.9.x (or 0.8.x) available ?
The docs generated by doxygen from the alsa-lib sources are available at
http://www.alsa-project.org/alsa-doc/alsa-lib/.
HTH
Clemens
Bruce Paterson wrote:
Am I sending these queries about the operation of alsa through the API
to the right place ? I'm trying to use alsa for a real scientific
application and I'm starting to worry it simply isn't ready yet.
I don't pretend to be a developer of alsa drivers themselves, and I'd
Am I sending these queries about the operation of alsa through the API
to the right place ? I'm trying to use alsa for a real scientific
application and I'm starting to worry it simply isn't ready yet.
I don't pretend to be a developer of alsa drivers themselves, and I'd
hoped I didn't need to
Hi All,
I am viewing ALSA 0.5.0 Developer documentation at
http://www.math.tu-berlin.de/~sbartels/alsa/
I would like to know if there is any Developer documentation for
ALSA 0.9.x (or 0.8.x) available ?
Regards,
Alamy Liu
---
This SF.net
Ok, thanks for the line out help, and I think I understand how the
matrix mixer works, and I can hear stuff through my monitors, but now I
can't figure out how to get alsa input or output functioning. I can
plug in my mic/pre and hear that through the monitors, and I can use the
oss compatability
Ok, thanks for the line out help, and I think I understand how the
matrix mixer works, and I can hear stuff through my monitors, but now I
can't figure out how to get alsa input or output functioning. I can
plug in my mic/pre and hear that through the monitors, and I can use the
oss compatability
Paul Davis wrote:
the APIs that are used to write almost all audio software code in
production these days all use a callback model.
Sorry for questioning this statement. Of course we all don't have any statisti
cal data but
you miss what I see as the majority of applications that use
That makes sense. I also fully agree that callback-driven APIs are better suited for
audio. On the other hand, nobody would doubt that o/c/r/w apps would not allow low
enough
latency for GUI-type apps like EQs (e.g. with buffer sizes of 10-20ms the total latency
isn't so inacceptable).
But
After having been pretty busy at work the past few weeks, this morning
I decided to give this testing another shot. Last time I had been able
to dicern or notice any change at all when most of the switches were
fliped... this time amixer/alsamixer simply seg faults. On console the
kernel just
Bruce Paterson wrote:
Thanks for your reply Daniel.
Daniel Haus wrote:
Behaviour:
The output sound is perfect for about 2 minutes. After that every now
and then I get distortion in the audio. No xruns or errors are
reported in the software. It sounds like only part of the output
buffer is
I tried to update the cvs here last night and was getting an error
installing the alsa-driver.
Something about unresolved symbols in snd.o
Going back to cvs from the 18/11 the problem is not there.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
At Mon, 18 Nov 2002 10:54:09 -0800 (PST),
Guilhem Tardy wrote:
Hi all,
Could anyone tell me the purpose of the index field in struct snd_kcontrol_t
?
if there are controls with the same name (e.g. a card with several
codec chips), they can be distinguished by different indices.
Takashi
Hi Jaroslav,
i'm back from vacation now.
At Mon, 25 Nov 2002 19:15:41 +0100 (CET),
Jaroslav wrote:
Hello all,
the subject says everything. CVS contains first code to avoid
oops / systems hangs when a running hotplug device is removed from the
system. Please, test and report
On Wed, 27 Nov 2002, Patrick Shirkey wrote:
Jaroslav Kysela wrote:
Hello all,
the subject says everything. CVS contains first code to avoid
oops / systems hangs when a running hotplug device is removed from the
system. Please, test and report problems.
I have updated and
Jaroslav Kysela wrote:
Hello all,
the subject says everything. CVS contains first code to avoid
oops / systems hangs when a running hotplug device is removed from the
system. Please, test and report problems.
I have updated and now when I disconnect the device it will not register
on
Jaroslav Kysela wrote:
Note that you'll have to terminate all applications using that soundcard
before you'll try to reconnect the device again. In next code, hopefully
the applications will be somehow terminated to make the cleanup process
automatic.
Ok. That's the probable cause as I am
On Wed, 27 Nov 2002, Patrick Shirkey wrote:
Jaroslav Kysela wrote:
Note that you'll have to terminate all applications using that soundcard
before you'll try to reconnect the device again. In next code, hopefully
the applications will be somehow terminated to make the cleanup process
Hi,
there was no ad1816 document on ftp.alsa-project.org and so I was looking
around and I found one here, but I don't know how long it's there...
http://theblue.net/hardware/datasheet/Converter/AD1816.PDF
martin
--
2b|!2b
---
This
Hi,
At Tue, 26 Nov 2002 10:04:45 +0530,
Pannaga Bhushan wrote:
Hi all,
I have a cs4236 chipset which was working fine till abt 5 days
back. but now seems to have gone dead. i just cannot get any sound out
of it at all.
then, could you try again the old version whether it really
[EMAIL PROTECTED] wrote:
Hello,
I allways have the same bug when trying to modprobe the cs4232 or cs4236
sounddriver for my Terratec EWS654XL soundcard.
The bug is called unresolved symbol, this bug exists in ALSA 0.9 since the
existing of ALSA 0.9.
I tried nearly every ALSA 0.9x version.
87 matches
Mail list logo
