At Wed, 12 Feb 2003 18:00:29 -0500,
Brian J. Tarricone [EMAIL PROTECTED] wrote:
just a quick update - i installed yesterday's cvs of alsa-driver, and i
haven't had any problems (no alloc failures or apps locking up) since
then. i've tried to stress test it a bit (filling up ram, opening
Hi,
At Wed, 12 Feb 2003 14:35:29 -0800,
Ryan Pavlik wrote:
On Wed, 12 Feb 2003 21:41:50 +0100 (CET)
Jaroslav Kysela [EMAIL PROTECTED] wrote:
snip
It seems that mtpav don't remeber the old status byte for each
channels. If it's true, then we need to take care about the expansion
in
At Wed, 12 Feb 2003 21:07:40 +0100,
Orm Finnendahl wrote:
Hi Justin, all,
Am Mittwoch, den 12. Februar 2003 um 19:30:00 Uhr (+) schrieb
Justin Cormack:
ie add the 0xb revision.
that did the trick. Seems to work fine now. I can't check all the way,
as I'm in Berlin and the
At Wed, 12 Feb 2003 18:54:01 +0100,
Josh Buhl wrote:
When running Quake 3 Arena the sound initializes
properly and plays correctly during the game until the
end of a match. At this point, the game abruptly enters
a different mode (this is where the models of the
players for the first,
Hi,
check LAD site,
http://www.linuxdj.com/audio/lad/resourceslatency.php3
you'll find some good information how to get low-latency.
Takashi
At Wed, 12 Feb 2003 17:56:19 -0500,
Chris Raphael wrote:
Hello List,
This is my first post and I am new (a couple of weeks) to ALSA.
Hi Takashi,
could you check whether the interrupts properly generated during the
repeated sounds?
I'll be happy to do whatever I can, but I don't exactly know what you
mean. How do I check whether the interrupts are properly generated?
I'm fairly certain that I don't have any irq conflicts:
A simple question, does the current Alsa release tarball work out of the box ?as is?,
i.e. ./configure ;make install on Debian current release, compiled kernel 2.4.20.
I am doing some work on the es18xx.c and don?t want to hit my head in the wall if
there are any problems with respect to the
At Thu, 13 Feb 2003 11:08:03 +0100,
Josh Buhl wrote:
Hi Takashi,
could you check whether the interrupts properly generated during the
repeated sounds?
I'll be happy to do whatever I can, but I don't exactly know what you
mean. How do I check whether the interrupts are properly
Hi Takashi,
Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb
Takashi Iwai:
ie add the 0xb revision.
i don't see the mails on ML, so not 100% sure how to fix (although i
guess above mentioned to add the new revision in the check in
snd_rme9652_create()...)
Yes. In
check /proc/interrupts during the playback whether the number of irq
10 increases.
During the looped sound, the number of interrupts increases by about
fifty a second:
josh@spleen:/proc$ date; cat interrupts | grep SiS
Thu Feb 13 11:41:10 CET 2003
10: 64806 XT-PIC SiS SI7012
Hi, I discovered a bug in the emu10k1 driver which I'll explain here:
I was developing an application which uses the timestamps given in the
status of the device to send S/PDIF data to it. This app worked pretty
well except that sometimes I heard sound discontinuities and then a
constant time
On Thu, Feb 13, 2003 at 11:44:24AM +0100, Orm Finnendahl wrote:
Hi Takashi,
Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb
Takashi Iwai:
ie add the 0xb revision.
i don't see the mails on ML, so not 100% sure how to fix (although i
guess above mentioned to
At Thu, 13 Feb 2003 12:08:51 +0100,
Martin Langer wrote:
On Thu, Feb 13, 2003 at 11:44:24AM +0100, Orm Finnendahl wrote:
Hi Takashi,
Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb
Takashi Iwai:
ie add the 0xb revision.
i don't see the mails on
Hi all,
I recently installed an Asus P4PE with built in AD1980 audio codec
(accessible through the ICH4 south bridge). The latest ALSA drivers
detected the chip and AC97 audio correctly even setting up the
IEC958 controls. The problem is I still got no output on the external
S/PDIF module.
I
I'm running alsa-0.9rc7 just fine on a slightly modified Debian 3.0r1
(I've upgraded a few packages to versions in sarge or sid) with kernel
2.4.20.
I did not use the regular alsa tarball, but rather the
alsa-source_0.9.0rc7-1_all.deb available in sid. I made it with
make-kpkg --revision
At Thu, 13 Feb 2003 03:19:02 -0800,
Jaroslaw Sobierski wrote:
Hi all,
I recently installed an Asus P4PE with built in AD1980 audio codec
(accessible through the ICH4 south bridge). The latest ALSA drivers
detected the chip and AC97 audio correctly even setting up the
IEC958 controls.
The information about the emagic unitor8 has also this
Der Befehl F5 gefolgt von einem Datenbyte bestimmt die gerade aktive
Kabelnummer (0,1,2,3 ... 64).
Ist die Kabelnummer=0 werden alle MIDI Messages auf allen MIDI Outs
ausgegeben (alle Outs von allen Boxen).
At Mon, 10 Feb 2003 18:21:12 +0100,
Arnaud de Bossoreille de Ribou wrote:
Hi, I discovered a bug in the emu10k1 driver which I'll explain here:
I was developing an application which uses the timestamps given in the
status of the device to send S/PDIF data to it. This app worked pretty
well
At 13 Feb 2003 12:54:39 +0100,
Immanuel Litzroth wrote:
The information about the emagic unitor8 has also this
Der Befehl F5 gefolgt von einem Datenbyte bestimmt die gerade aktive
Kabelnummer (0,1,2,3 ... 64).
Ist die Kabelnummer=0 werden alle MIDI Messages auf allen
At Wed, 12 Feb 2003 20:21:31 +0100 (CET),
Jaroslav wrote:
On Wed, 12 Feb 2003, Marc Titinger wrote:
This looks Great !
I haven't yet experimented a lot with .asoundrc files, so please excuse
me if the following questions are irrelevant or OTO, but:
I was wondering if one could
On Thu, Feb 13, 2003 at 12:13:46PM +0100, Takashi Iwai wrote:
At Thu, 13 Feb 2003 12:08:51 +0100,
Martin Langer wrote:
On Thu, Feb 13, 2003 at 11:44:24AM +0100, Orm Finnendahl wrote:
Hi Takashi,
Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb
Takashi Iwai:
well, route (or plug) has the capability for software mix (in a
certain meaning), but not for separate pcm streams. you can downmix
the multi-channels in a stream via route plugin if the channels is
given.
but it's defenitely different from what dmix plugin does, and perhaps
it's
Thanks for responding Paul.
I'm using Red Hat 7.2 which is the 2.4 kernel and the 0.9.0rc7 ALSA driver.
I'm not sure why you want to know about the disk controller since there
is no disk access in the real-time part of my application. But I am using
a Dell Inspiron 8200 and I looked on the web
Hi Allan,
recently a technical information about emagic unitor8 was revealed,
and it includes a small desription about MTP, too.
there, the initialization sysex is mentionted, so perhaps this may
influence on the behavior of the device. (also, the smpte sysex is
described!)
before i start
trying to summarize 3-4 years of experience with this is hard. but
lets start by pointing out that its possible that your disk controller
causes the kernel to delay scheduling for up to 100msecs. i'm not sure
if RH7 fixed this by setting the driver parameters correctly - i have
heard that newer
Hello,
I am experiencing lots of problems accessing cvs.alsa-project.org
bitone:~/alsa-cvs# cvs update alsa-lib
cvs [update aborted]: end of file from server (consult above messages if any)
bitone:~/alsa-cvs# cvs update alsa-lib
cvs [update aborted]: reading from server: Connection reset by
recently a technical information about emagic unitor8 was revealed,
I suppose this doesn't mention AMT? Can I have this information. It
might contain more than what I already have.
and it includes a small desription about MTP, too.
there, the initialization sysex is mentionted, so perhaps
At Thu, 13 Feb 2003 16:05:00 +0100,
Martijn Sipkema wrote:
recently a technical information about emagic unitor8 was revealed,
I suppose this doesn't mention AMT? Can I have this information. It
might contain more than what I already have.
the info appeared in another thread
[...]
I suppose this doesn't mention AMT? Can I have this information. It
might contain more than what I already have.
the info appeared in another thread (running-status bug on mtpav):
http://www.math.tu-berlin.de/~sbartels/unitor/unitor8_doc.txt
the project itself seems dead now...
Yes, and thanks for the help, It seems to work to compile the source from the tarball
the ordinary way also.
Progress-report on the es18xx.c on ES1878:
* I found the nd_es18xx_dsp_get_byte() to be inconsistent with the spec. and rewrote
it accordingly.
static int
On Thu, 2003-02-13 at 13:18, Martin Langer wrote:
On Thu, Feb 13, 2003 at 12:13:46PM +0100, Takashi Iwai wrote:
At Thu, 13 Feb 2003 12:08:51 +0100,
Martin Langer wrote:
On Thu, Feb 13, 2003 at 11:44:24AM +0100, Orm Finnendahl wrote:
Hi Takashi,
Am Donnerstag, den 13. Februar 2003
I wrote:
The problem I described in my previous mail (no more calls to
snd_pcm_jack_mmap_commit after start) still occurs though... Any
idea what might be the problem, or where to look?
Okay, I fixed this. It was a missing
pcm-poll_events = POLLIN;
(after pcm-poll_fd = fd[1] , in
On Thu, 13 Feb 2003, Takashi Iwai wrote:
Hi,
At Wed, 12 Feb 2003 14:35:29 -0800,
Ryan Pavlik wrote:
On Wed, 12 Feb 2003 21:41:50 +0100 (CET)
Jaroslav Kysela [EMAIL PROTECTED] wrote:
snip
It seems that mtpav don't remeber the old status byte for each
channels. If it's true,
On Thu, 13 Feb 2003, Takashi Iwai wrote:
agreed here, although i feel it's also nice to set it as default for a
consumer card which has no hardware mix function.
We can add the special configuration to card-specific configuration files
(like for surround*, spdif etc.), but I was too lazy to do
Hello,
I am working on adding native alsa support to the Helix project, and am
running into issues I think are with threading between the two.
Mainly, variable values are returning as 0 when they shouldn't be.
such as
function(int bleh) {
bleh = 1;
}
when function() returns, bleh == 0 in the
Attached you find the patch with my latest changes. Both playback and
capture from jack work now, though not simultanously.
$ jackd -d alsa -p 4096 -d hw:0
$ aplay -Dmyplug /usr/share/sounds/KDE_Startup.wav
$ arecord -Dmyplug -d 4 foo.wav
(see my previous mail on how to define myplug)
Now, my
On Thu, 13 Feb 2003 17:27:25 +0100 (CET)
Jaroslav Kysela [EMAIL PROTECTED] wrote:
snip
Unfortunately, the patch is not perfect. I think that we need to
buffer the whole MIDI message and send it after completion, because
it's possible, that you'll get only partial MIDI message from the
Paul, Again thanks very much. From:
/sbin/hdparm /dev/hda2
I get:
/dev/hda2:
multcount = 16 (on)
I/O support= 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8
Also check out the Planet for more info on this. Fernando has some
suggestions for Redhat there.
Cheers,
Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis
Sent: Thursday, February 13, 2003 11:11 AM
To: Chris Raphael
Cc: [EMAIL PROTECTED]
On Thu, 13 Feb 2003, Takashi Iwai wrote:
At Mon, 10 Feb 2003 18:21:12 +0100,
Arnaud de Bossoreille de Ribou wrote:
Hi, I discovered a bug in the emu10k1 driver which I'll explain here:
I was developing an application which uses the timestamps given in the
status of the device to
Paul, Okay I looked at the page you pointed me to with info about
hdparm. before I changed any of the controller settings I
got 21.12 MB/sec for Timing buffered disk reads which seems to be
pretty good according to the
author of the web page. After changing the settings (I/O support
32 bit,
On Thu, 13 Feb 2003, Ryan Pavlik wrote:
On Thu, 13 Feb 2003 17:27:25 +0100 (CET)
Jaroslav Kysela [EMAIL PROTECTED] wrote:
snip
Unfortunately, the patch is not perfect. I think that we need to
buffer the whole MIDI message and send it after completion, because
it's possible, that
On Thu, 13 Feb 2003, Maarten de Boer wrote:
Attached you find the patch with my latest changes. Both playback and
capture from jack work now, though not simultanously.
$ jackd -d alsa -p 4096 -d hw:0
$ aplay -Dmyplug /usr/share/sounds/KDE_Startup.wav
$ arecord -Dmyplug -d 4 foo.wav
On Mon, 10 Feb 2003, Arnaud de Bossoreille de Ribou wrote:
So the bug looks like a signedness problem since sw_ready is unsigned
and there is a while(sw_ready 0), which explain the constant delay,
next in the snd_emu10k1_fx8010_playback_transfer function.
So the emu10k1.patch file attached
Hi again,
seems I was following a red herring. My debugger mislead me.
The function 'snd_pcm_open()' isn't the culprit, it really dies here:
==
int rc = 0;
int exactRate
= snd_pcm_hw_params_set_rate_near (capture_handle, hw_params,
uSampleRate, rc);
if(rc
On Thu, 13 Feb 2003, M. Ritscher wrote:
Hi again,
seems I was following a red herring. My debugger mislead me.
The function 'snd_pcm_open()' isn't the culprit, it really dies here:
Before we start any debugging - are you using the alsa-lib from CVS? I've
fixed some problems which may
(cvs version 2003-02-13)
/sbin/modprobe snd-trident
Note: /etc/modules.conf is more recent than
/lib/modules/2.4.19/modules.dep
/lib/modules/2.4.19/kernel/sound/pci/trident/snd-trident.o: init_module:
No such device
Hint: insmod errors can be caused by incorrect module parameters,
including
On Thu, 2003-02-13 at 12:56, Pete Barnard wrote:
:
Does it always crash after the same time?
No. It didin't crash after the same time. The problem is fixed now thanks
to Josh Green's tip. (I wrote a function that caught the EPIPE error and
then did a snd_pcm_prepare). I left it for 2
Hi Takashi
This is fantastic news!!
I haven't got a working build of MusE probably until later this weekend.
I have to go and engineer a gig later today and I'm sick today so I
can't seem myself doing much till tomorrow.
Basically it seemed to receive timecode (MIDI CLOCK and MTC) okay from
Hi Jaroslav,
Before we start any debugging - are you using the alsa-lib from CVS? I've
fixed some problems which may relate to your report a few days ago.
No, I'm using 0.9rc7. Seems I have to make myself familiar with using the
CVS version than.
Cheer,
Meinhard
--
+++ GMX - Mail,
Pavel,
You're in the wrong forum. Go to www.linux1394.org and pick up the
information you need to get started there. If you want to develop 1394
applications there are some mailing lists there with other like minded
people.
Good
luck,
Mark
-Original Message-From:
[EMAIL
I would like to ask about situation in Linux about one problem.
Does Linux kernel or Alsa drivers supports IEEE 1394 standart?
If yes, could you recomend me some references and advices to be able to =
use it
and program it to create applications with IEEE 1394?
If no, could you recomend me some
At Wed, 12 Feb 2003 11:49:08 -0500,
Paul Davis wrote:
when ardour is in a state where i believe (rightly or wrongly) that a
reasonably typical target user can sit down and just use it without
encountering bugs when recording a typical 12-32 track piece, there
will be binaries.
don't forget
don't forget that the binary distribution may cause different kind of
problems, too.
the binary might not run on different distributions, or even on a
different machine with a same distribution, unless you give
all-static-linked binary. (note that even a binary like netscape 4.x
cannot run
Hi,
I would like to ask about situation in Linux about
one problem.
Does Linux kernel or Alsa drivers supports IEEE
1394 standart?
If yes, could you recomend me some references and
advices to be able to use it
andprogram itto
createapplications with IEEE 1394?
If no, could you recomend me
55 matches
Mail list logo
