ok, i added more printk's in the trident driver to track exactly what
the interrupt sequence is.
and what do you know ... if i add just one printk at the top, this
doesn't stop things going wrong. if i add two printk's to tell me more
about the nature of the interrupts, suddenly, everything works
On Wed, 2001-11-28 at 18:36, A Grant wrote:
> I'm interested in getting snd up and working and have compiled it with alsa support.
>I have a Turtle Beach Santa Cruz using 2.4.16 and cs46xx beta9 drivers and libs.
>
> Here's the prob:
>
> :~$ snd
> ALSA lib pcm_hw.c:598:(snd_pcm_hw_open) SNDRV_P
On Wed, 28 Nov 2001, dave willis wrote:
> after some unknown amount of time, when there is no audio being played
> through my soundcard, my mixer levels are all reset. this happens
> sometimes even if i was playing audio 1 minute ago, and on both of my
> soundcards (ice1712/ymfpci). i don't kno
On Wed, 2001-11-28 at 15:51, Paul Davis wrote:
>
> is there any existing code that uses poll(2) for full duplex and
> demonstrates working operation?
>
> --p
>
I've attached the test code that I wrote with Jaroslav's modifications
which uses poll. It still has the clicking problem I menti
this is a trace generated with printk, rdtscll and some post-perl
munging. the cycles were trimmed to the significant range. i have
added commentary.
i am tracing 3 functions in the ALSA kernel code:
snd_pcm_capture_poll
snd_pcm_playback_poll
snd_pcm_hw_ptr_interrupt
both poll routines ha
On Wed, 28 Nov 2001, Dave Andruczyk wrote:
> >
> > As far as I can tell, my DMA and IRQ settings are correct. The relevant
> > settings from my /etc/modules.conf are:
> >
> > alias char-major-116 snd
> > options snd snd_major=116 snd_cards_limit=1
> > alias snd-card-0 snd-card-ad181
On Wed, 2001-11-28 at 05:47, Paul Davis wrote:
>
> do you think this is possible/likely? if it is, do you think that its
> the job of the low level driver(s) to handle this? otherwise, its hard
> for me to see how an application (or library) can handle this
> efficiently in any full-duplex sit
yeah, as usual, i forgot the insanely elegant but obscure way that
poll works inside the kernel ... poll_wait() doesn't block the task.
continuing my explorations.
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listin
I'm interested in getting snd up and working and have compiled it with alsa support. I
have a Turtle Beach Santa Cruz using 2.4.16 and cs46xx beta9 drivers and libs.
Here's the prob:
:~$ snd
ALSA lib pcm_hw.c:598:(snd_pcm_hw_open) SNDRV_PCM_IOCTL_PVERSION failed: Inappropriate
ioctl for device
ok, i added "duplex polling with retry". i am now seeing interesting
behaviour that i need to understand (and correct):
1) the behaviour (see trace below)
2) summary
if capture is not ready at the same time as playback, returning to
poll to wait for capture often works. but not always. sometimes
On Wednesday 28 November 2001 23.19, you wrote:
> >gcc -O2 -Wall -fPIC -c bfio_alsa.c
> >ld -shared -o alsa.bfio bfio_alsa.o -lasound
>
> i don't think you can't build shared libraries like this unless you
> have the right kind of object for libasound, and i'm not sure that
> *.so is not the right
Same alsa-lib snapshot, same machine, but gcc3.0.2 and compile goes
through without problems.
On Thu, 29 Nov 2001, Kai Vehmanen wrote:
> While compiling the latest CVS-tree I get the following... any ideas?
>
> [ ... alsa-lib/src/pcm/ ]
> /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_
On Wed, 28 Nov 2001, Anders Torger wrote:
> I'm making a software which will be using ALSA through a plugin implemented
> as a shared library. The idea is that the main software has no sound-API
[...]
> ALSA lib dlmisc.c:94:(snd_dlsym_verify) unable to verify version for symbol
> snd_config_ho
While compiling the latest CVS-tree I get the following... any ideas?
[ ... alsa-lib/src/pcm/ ]
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../include
-I../../include-g -O2 -c pcm_lfloat.c
gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -g -O2
-Wp,-MD,.
On Wed, Nov 28, 2001 at 11:40:58PM +0100, Wolfgang Hoffmann wrote:
> To me it's not clear why protecting a ringbuffer with a mutex
> is evil. Is it simply the problem of "abuse", in the sense of one client
> locks the mutex longer than necessary (i.e. longer than just
> copying data to/from the b
>gcc -O2 -Wall -fPIC -c bfio_alsa.c
>ld -shared -o alsa.bfio bfio_alsa.o -lasound
i don't think you can't build shared libraries like this unless you
have the right kind of object for libasound, and i'm not sure that
*.so is not the right kind of object.
it seems that you're trying to express a
>I tried to run the ardour-package that Takashi Iwai provides on
>ftp://ftp.suse.com/pub/people/tiwai/alsa9-packages/7.3-src/
>but it seems that exactly due to this it won't run. Too bad, ardour
>look very very promising on the web-pages!
I respectfull request, with great vigor, that Takashi remo
>I saw you pointing to the problematic usage of mutex with
>ringbuffers a couple of times now. In the most recent case
>you mentioned a solution of yours without mutices (sorry,
>I can't find the reference anymore ... probably was on LAD).
>
>To me it's not clear why protecting a ringbuffer with a
>From a recent thread I learned that my RME DIGI96 only
allows period sizes of 2048 or 8192 bytes. No other choices,
due to hardware design. So what if the applications asks for
256 bytes? If the applications insists on that, it won't run. If
it asks for "near", it'll get not what it expects, but
I'm making a software which will be using ALSA through a plugin implemented
as a shared library. The idea is that the main software has no sound-API
specific code whatsoever, and that one can easily write a plugin which is
loaded in runtime to provide support for ALSA, OSS, file or whatever.
Paul,
I saw you pointing to the problematic usage of mutex with
ringbuffers a couple of times now. In the most recent case
you mentioned a solution of yours without mutices (sorry,
I can't find the reference anymore ... probably was on LAD).
To me it's not clear why protecting a ringbuffer with
>> ok, i'll go get my daughter from school and think about this on
>> the way there and back. maybe full duplex poll is required, but it
>> seems awfully heavyweight for full duplex h/w where the playback and
>> capture streams should be running synchronously.
>
>In this case you'd have both reven
Paul Davis wrote:
>
> ok, i'll go get my daughter from school and think about this on
> the way there and back. maybe full duplex poll is required, but it
> seems awfully heavyweight for full duplex h/w where the playback and
> capture streams should be running synchronously.
In this case you'd
Emmanuel Fleury wrote:
I have also a freez.
This is on the midipart. I have got it two times now. And the oops is not
in my kernel log so I got it by paper. I hope this can help.
My test is simple:
run pmidi-1.5.4 (more then one at once)
And start and stop them with kill -STOP/-CONT.
After a whi
On Wed, 28 Nov 2001, Emmanuel Fleury wrote:
> Jaroslav Kysela wrote:
>
> > On Wed, 28 Nov 2001, Steve Harris wrote:
> >
> > It's very much better to use the alsa-driver/utils/insert script, and look
> > to alsa-driver/snd.map file for the IP address, where driver crashed. We
> > can determine eas
after some unknown amount of time, when there is no audio being played
through my soundcard, my mixer levels are all reset. this happens
sometimes even if i was playing audio 1 minute ago, and on both of my
soundcards (ice1712/ymfpci). i don't know if it's an alsa thing or some
other linux thing
Jaroslav Kysela wrote:
> On Wed, 28 Nov 2001, Steve Harris wrote:
>
> It's very much better to use the alsa-driver/utils/insert script, and look
> to alsa-driver/snd.map file for the IP address, where driver crashed. We
> can determine easily the function.
Ooops, I already got the Sys Rq key in
here are two consecutive return-from-poll situations:
--
poll events = 0x4, checking capture avail
capture: hwptr = 193 apptr = 128 <= OK, hwptr += 64, apptr += 64
checking playback avail
playback: hwptr = 193 apptr = 256 <= OK, hwptr += 63, appptr += 64
hw avail: c:6
On Wed, 28 Nov 2001, Paul Davis wrote:
> after hacking both the kernel driver and alsa-lib, this is the view
> from user-space. each block between "" is single return from
> poll(2). i added code to print the values of the hw_ptr and appl_ptr
> from within alsa-lib.
>
> --
Here is a segment of my .asoundrc.
pcm_slave.rme9652_s {
pcm rme9652_0
}
pcm.rme9652_1 {
type hw
card 1
}
ctl.rme9652_1 {
type hw
card 1
}
pcm.rme9652_0 {
type hw
card 0
}
ctl.rme9652_0 {
type hw
card 0
}
ctl.rme9652_48 {
typ
in order to compile kernel in core kernel when module support is _disabled_,
you need to apply this :
--- /usr/src/alsa-driver-0.9.0beta9/kernel/sound.c Fri Oct 12 10:43:18 2001
+++ sound.c Wed Nov 28 12:58:01 2001
@@ -26,9 +26,7 @@
#include
#include
#include
-#ifdef CONFIG_KMOD
#
From: Emmanuel Fleury <[EMAIL PROTECTED]>
> Steve Harris wrote:
> > On Wed, Nov 28, 2001 at 01:12:17AM +0100, Emmanuel Fleury wrote:
> >
> > If you're hitting the same bug as me then the oops never gets written
> > because the IRQ handler gets disabled.
>
> I don't know exactly if it is the same
make[1]: Entering directory
`/home/darren/build/alsa-utils-0.9.0beta9/aplay'
gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include-g -O2 -c
aplay.c
aplay.c: In function `main':
aplay.c:473: `snd_pcm_mmap_writei' undeclared (first use in this
function)
aplay.c:473: (Each undeclared identifi
after hacking both the kernel driver and alsa-lib, this is the view
from user-space. each block between "" is single return from
poll(2). i added code to print the values of the hw_ptr and appl_ptr
from within alsa-lib.
---
hwptr = 65 apptr = 0
hwptr = 128 apptr = 64
hw a
I don't know all about mmap, but why does one need to poll.
I would have thought that a callback with info on how many samples it wants
would be a better way.
Cheers
James
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis
> Sent: 28 Novemb
On Wed, 28 Nov 2001, Paul Davis wrote:
> Jaroslav, you wrote:
>
> avail = capture_avail < playback_avail ?
> capture_avail : playback_avail;
>
> /* here is very bad assumption, that all drivers are able */
> /* todo f
On Wed, 28 Nov 2001, Abramo Bagnara wrote:
> I think that you can easily solve the problem of missing frames from
> capture or playback simply calling poll a first time with both stream
> and a second time with the missing one.
>
> In this way you solve the problem without the busy loop.
That's
>I don't know all about mmap, but why does one need to poll.
>I would have thought that a callback with info on how many samples it wants
>would be a better way.
there is no generalized mechanism for the kernel to call userspace code.
POSIX signals are the canonical examples of such a thing, whe
>I think that you can easily solve the problem of missing frames from
>capture or playback simply calling poll a first time with both stream
>and a second time with the missing one.
>
>In this way you solve the problem without the busy loop.
thats true.
however, as we've seen, that wasn't the na
Jaroslav, you wrote:
avail = capture_avail < playback_avail ?
capture_avail : playback_avail;
/* here is very bad assumption, that all drivers are able */
/* todo full duplex with same period sizes, it would be bette
I have not looked at the source code, but the SDL audio code uses callbacks.
I think JACK also uses callbacks.
Are these all doing "highly specific mechanism with lots of semantics" ?
Cheers
James
> -Original Message-
> From: Paul Davis [mailto:[EMAIL PROTECTED]]
> Sent: 28 November 20
I think that you can easily solve the problem of missing frames from
capture or playback simply calling poll a first time with both stream
and a second time with the missing one.
In this way you solve the problem without the busy loop.
--
Abramo Bagnara mailto:[EMAIL PROT
>I have not looked at the source code, but the SDL audio code uses callbacks.
>I think JACK also uses callbacks.
>
>Are these all doing "highly specific mechanism with lots of semantics" ?
no. they are userspace-to-userspace callbacks that are driven by a
return from poll(2), select(2), read(2) o
>> true, except that we enforce this requirement at a different
>> level. you can't get a synchronous engine to run correctly if the
>> capture and playback streams are not usable in the same basic way.
>>
>> or can you?
>
>Yes, you can find the nearest transfer count for both streams.
Sure, that
On Wed, 28 Nov 2001, Jeremy Hall wrote:
> Hi,
>
> Today I saw what is believed to be data corruption. In the middle of
> snd_pcm_multi_avail_update, I discovered:
>
> (gdb) print *multi->slaves
> $13 = {pcm = 0x5, channels_count = 5, close_slave = 5, linked = 5}
> (gdb)
>
> WHen it tried to call
On Wed, 28 Nov 2001, Steve Harris wrote:
> On Wed, Nov 28, 2001 at 01:12:17AM +0100, Emmanuel Fleury wrote:
> >
> > My BIG problem was that I really can't get any log from this problem.
> > No ooops, no strace output (the file was existing but was empty), no
> > syslog, nothing ! :-/
>
> If you'r
On Wed, 28 Nov 2001, Paul Davis wrote:
> >non-continous transfers. The right loop, based on the period_size
> >transfers, should be like this:
> >
> > poll();
> > if ((pfd->revents & POLLIN) {
> > while (1) {
> > if (snd_pcm_avail_update(pcm) < period_size)
Hi,
I cannot get the oss emulation of the synth going. pmidi works fine,
but cat /proc/asound/sndstat:
Sound Driver:3.8.1a-980706 (ALSA v0.9.0beta7 emulation code)
Kernel: Linux zodiac 2.4.14a #1 Mon Nov 19 20:11:48 CET 2001 i686
Config options: 0
Installed drivers:
Type 10: ALSA emulation
Ca
one last little bit of info. i added another printf to check on
something. it seems that with the trident driver, we are able to
return from a poll(2) on the capture device even when
snd_pcm_avail_update() tells us (as we expect) that there are *zero*
frames available. this seems like a clear cut
>> count = (avail / period_size) * period_size;
>
> count = avail - avail % period_size;
>
>is more efficient (at least on i386 and gcc).
thanks for reminding me. alas, there is still a problem. could it just
be a device-specific issue? its as if the snd_pcm_mmap_commit doesn't
work on
Paul Davis wrote:
>
> solved. it turned out that "trusting" the driver was key:
>
> >> if (snd_pcm_avail_update(pcm) < period_size)
> >> break;
> >> count = period_size;
>
> this was the key point. sometimes when we returned
solved. it turned out that "trusting" the driver was key:
>> if (snd_pcm_avail_update(pcm) < period_size)
>> break;
>> count = period_size;
this was the key point. sometimes when we returned from poll(2),
snd_pcm_avail_update
Steve Harris wrote:
> On Wed, Nov 28, 2001 at 01:12:17AM +0100, Emmanuel Fleury wrote:
>
> If you're hitting the same bug as me then the oops never gets written
> because the IRQ handler gets disabled.
I don't know exactly if it is the same than you. I don't have enough
information to be sure
Jaroslav Kysela wrote:
>
> On Wed, 28 Nov 2001, [iso-8859-1] Jörn Nettingsmeier wrote:
>
> > it says:
> > make: No rule to make target
> > /usr/src/linux/include/linux/hostfs_fs_i.h
> >
> > cvs was pulled yesterday and 5 mins ago, same problem.
> > sorry i don't have the time right now to invest
On Wed, Nov 28, 2001 at 01:12:17AM +0100, Emmanuel Fleury wrote:
>
> My BIG problem was that I really can't get any log from this problem.
> No ooops, no strace output (the file was existing but was empty), no
> syslog, nothing ! :-/
If you're hitting the same bug as me then the oops never gets
>non-continous transfers. The right loop, based on the period_size
>transfers, should be like this:
>
> poll();
> if ((pfd->revents & POLLIN) {
> while (1) {
> if (snd_pcm_avail_update(pcm) < period_size)
> break;
>
Hi again,
Some new infos (just in case somebody is interested :-)).
The Alsa-OSS modules are not involved (it crash even if they are not loaded.
I tried to reach my computer via the network after a crash. Suprisingly,
ping is working fine but neither ssh neither telnet or ftp or anything
is
On Wed, 28 Nov 2001, [iso-8859-1] Jörn Nettingsmeier wrote:
> it says:
> make: No rule to make target
> /usr/src/linux/include/linux/hostfs_fs_i.h
>
> cvs was pulled yesterday and 5 mins ago, same problem.
> sorry i don't have the time right now to investigate whether this is
> an omission in the
On Wed, 28 Nov 2001, Steve Harris wrote:
> On Tue, Nov 27, 2001 at 12:30:21PM -0800, Dan Hollis wrote:
> > > ardour. If ardour segfaults or is kill -9'd the kernel oopses inside the
> > > alsa 1371 driver.
> > This seems to be a problem with current alsa. If i kill -9 return to
> > castle wolfenst
On Tue, Nov 27, 2001 at 12:30:21PM -0800, Dan Hollis wrote:
> > ardour. If ardour segfaults or is kill -9'd the kernel oopses inside the
> > alsa 1371 driver.
>
> This seems to be a problem with current alsa. If i kill -9 return to
> castle wolfenstein, I reliably get an oops. If i ^C it, there i
Hi,
Today I saw what is believed to be data corruption. In the middle of
snd_pcm_multi_avail_update, I discovered:
(gdb) print *multi->slaves
$13 = {pcm = 0x5, channels_count = 5, close_slave = 5, linked = 5}
(gdb)
WHen it tried to call
357 avail =
snd_pcm_avail_update(mu
one thing we desperately need for the inclusion in the kernel is a
working and complete mailing list archive.
i expect many new people taking a peek at alsa development now, if
only grumpy kernel hackers seeking reasons why oss is better :)
the geocrawler archive can only be described as an excus
it says:
make: No rule to make target
/usr/src/linux/include/linux/hostfs_fs_i.h
cvs was pulled yesterday and 5 mins ago, same problem.
sorry i don't have the time right now to investigate whether this is
an omission in the kernel tree, so i'm just posting here fyi.
the kernel boots and runs fine
Alan Cox wrote:
>>On Tue, 27 Nov 2001, Jaroslav Kysela wrote:
>>
>>>If nobody has comments, I'm ready to prepare a whole patch for Linus
>>>against the actual 2.5.1pre code.
>>>
>>My only comment: ALSA has waited long enough. It's now ready for hardcore.
>>
>
> Go for it.
Well, no choice now !
Duncan Sands wrote:
>
> Try using the magic SysRq key to get information (see the
> sysrq.txt file in the linux/Documentation directory of your
> kernel sources; you will probably have to recompile your
> kernel).
Good idea ! I wasn't thinking about it !
I will try, thanks
--
Emmanuel
We
Josh Green wrote
>
> So I take it machine is unusable after freeze?
Well, the freeze seems to stop all keyboard and mouse events.
The cursor is still blinking, and the mpeg123 weird bug is telling me
that the computer is somehow still active. But I didn't tried to reach
it by the network (I
> On Tue, 27 Nov 2001, Jaroslav Kysela wrote:
> > If nobody has comments, I'm ready to prepare a whole patch for Linus
> > against the actual 2.5.1pre code.
>
> My only comment: ALSA has waited long enough. It's now ready for hardcore.
Go for it.
___
On Tue, 27 Nov 2001, Jaroslav Kysela wrote:
> If nobody has comments, I'm ready to prepare a whole patch for Linus
> against the actual 2.5.1pre code.
My only comment: ALSA has waited long enough. It's now ready for hardcore.
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
Le Mardi 27 Novembre 2001 18:36, Jaroslav Kysela a écrit :
> On Tue, 27 Nov 2001, Nicolas DEVERGE wrote:
> > Hi,
> > I tried to use the current CVS version of the alsa lib and aserver tool.
> > I would like to use two instances of aplay in the same time.
> >
> > First, I tried with this configu
On Wed, 28 Nov 2001, Jaroslav Kysela wrote:
> On Tue, 27 Nov 2001, Paul Davis wrote:
>
> > enclosed below what happens when using ALSA, mmap mode and poll(2) on my
> > trident card at 44100. the value of contiguous is the value returned
> > by snd_pcm_mmap_begin() having been passed a value of 20
70 matches
Mail list logo
