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, Mess
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
o
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 i
:
>
> 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 nights with a system("date") in
the catch function and
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 re
(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 invali
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 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 a
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.
On Thu, 13 Feb 2003, Ryan Pavlik wrote:
> On Thu, 13 Feb 2003 17:27:25 +0100 (CET)
> Jaroslav Kysela <[EMAIL PROTECTED]> wrote:
>
>
> > 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, tha
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, 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 de
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]
Sub
>/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 (on)
> geometry = 4864/255
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 (on
On Thu, 13 Feb 2003 17:27:25 +0100 (CET)
Jaroslav Kysela <[EMAIL PROTECTED]> wrote:
> 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
> rawmi
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
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 PR
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
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 d
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:
> >
> >
> > > It seems that mtpav don't remeber the old status byte for each
> > > channe
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] ,
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.
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 snd_es18xx_dsp_get_byte(es18xx
[...]
> > 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
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 (runnin
> 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 t
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 peer
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 ver
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 coding
>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 m
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,
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 recomen
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 Iw
Jaroslav Kysela wrote:
>
> Hi all,
>
> a next step to get the lowlatency sharing of exclusive PCM devices
> is in ALSA CVS - the dmix (direct mixing) plugin..
> How it works? Basically, the playback in driver runs forewer
> without any xrun detection. The ring buffer (only just pl
> I've updated a bit your code, but I cannot test it myself, because I
> cannot connect to a jack port - invalid destination port name - (I'll
> look what's wrong tomorrow).
Thanks a lot for your updates.
The problem I described in my previous mail (no more calls to
snd_pcm_jack_mmap_commit af
>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 ru
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
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
>
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 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 cont
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 splee
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 d
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.
> > >
> > >
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
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 dela
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
j
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()...)
> 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 di
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 proper
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 pac
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:
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 A
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,
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
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 for
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
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:
>
>
> > 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
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, openi
59 matches
Mail list logo
