I've not managed to fix this bug into my program... Do you see the error on my
code (bad soundcard initialization or other) or have you got another way to
propose me to capture the two channels of my soundcard separately ?
try increasing BUF_SIZE to 4096 and see what happens. 128
frames/period
I followed the discussion: optical SPDIF output on Abit NF7 nforce2
main board.
I am using a similar Epox Mainboard with SPDIF in/out. Currently i am
using the todays cvs alsa version and have two questions:
Using gqmgeg which uses ogg123 to play ogg files, ogg123 seems to have
the samplerate
My second idea was to have a rather big hw buffer (500ms), and then set
the start_threshold to a low value (32 frames for instance). But whatever
my parameters were, I always got a playout delay of about the hw buffer
size.
the output latency is always roughly the size of the hardware
buffer.
I am working on a voice over IP application. We would like delays from
the write to soundcard to the actual playout lower than 50ms. Do you
think it is impossible with ALSA ? With OSS free the delay we got were
quite good, without any tweaking. But ALSA is said to have better
support for
This problem happens randomly but is very annoying, specially if I
program my PVR (MythTV) to automatically record a show - the show can
get recorded with metallic sound, which makes it very hard to understand
during playback.
This is not MythTV-specific since I have been able to reproduce the
At Mon, 03 Nov 2003 14:41:51 -0500,
Jonathan Kraut wrote:
Hello again. Further research:
I tried an earlier version of jack (0.71.0) with alsa-driver-0.9.8, accessin
g hw:0,2 via my .asoundrc. I get the same result as before, but in addition th
is particular version of jackd tells me:
again I've got a question regarding the ALSA midi sequencer. I tried to
generate Midi time code.
you cannot send 100% valid MIDI time code on a Linux system without
the high resolution timers patch or some other interrupt source that provides
a suitable timing resolution.
MIDI time code is not
anyway, it'd be helpful for debugging if someone can reproduce this
certainly under a fixed condition...
Well, about 3 times out of 7 I get the problem, so it's not hard to
reproduce at all. What I'd have to know is where to place the debugging
printk()'s or something like that :(
just wanted
I am trying to write an application that uses ALSA interrupt-driven
(which I guess is obtained by adding PCM handler(s) in ALSA?),
full-duplex (simultaneous capture/playback) using the ALSA PCM API
directly (i.e. not using JACK).
My question: do I only need to register one callback/handler
Many thanks for the info.!
just keep in mind what jaroslav noted about signal handling
context. please don't build a serious application around this
mechanism. sooner or later, you may want to make a system call from
the handler that violates the POSIX guarantees about what can be
done. at that
Hi,
it seems to me that with alsa 0.9.8 drivers it's not possible to load
snd-rme9652. With 0.9.7c there is no problem. The snd-hdsp driver works
in both versions (i tried both cards with both alsa versions).
error message:
modprobe snd-rme9652
1) just a quick note to point out that whether you know it or not, the
email program you are using is sending out copies of your mail in both
plain text and HTML formats. increasingly on the net, there are
filters being put in place that silently dump HTML-formatted
email. some mailing lists will
So, these are two numbers - and basicly all is fine as long as you dont wan=
t=20
to excede them, but if you do, you need to use dmix or dsnoop. Why not use=
=20
dmix and dsnoop automaticly when necessary ? Wouldnt it be possible to have=
because it would be catastrophic, or, well, at least very
what you say seems to be valid to me, but not if you implement smart dmix the
way I said =). The way I suggested *every* application would connect to smart
dmix, and none directly to alsa lib (except those that use devices like hw: -
and those should never be mixed). Since every stream is
well, my concern is that with the high-end cards, people tend to stick
with the quality of sounds. that means, any reason to reduce the
quality wouldn't be acceptable for some people. since dmix will do it
silently (if needed), it might be unacceptable.
what ? are you suggesting there are
On Mon, 17 Nov 2003, Paul Davis wrote:
what you say seems to be valid to me, but not if you implement smart dmix t
he
way I said =). The way I suggested *every* application would connect to sma
rt
dmix, and none directly to alsa lib (except those that use devices like hw:
-
and those should
the RME hardware has 16-26+ channels, but only one stream.
Ok,
here we come to my ignorance on sound drivers/hardware/terminology. If I ta=
lk=20
about a stream I mean one application -- soundcard link. What would a=20
channel be ? And what a stream if not what I defined a line up?=20
Maybe
5) I think that this sound mixing problem might be better served by
sound servers like jack.
Hmmm,
actualy I did have a very close look at jack, but the problem that I saw=20
(correct me if Im wrong here), is the fact that jack only works well if the=
=20
applications are specificaly geard to
If my hammerfall (rme9652) sound card is locked slave to 48 kHz, and I put
44.1 kHz into snd_pcm_hw_params_set_rate_near for playback it accepts it,
should it really be that way? I expected that it would set the rate to 48kHz,
since the card does not change the sample rate to 44.1 kHz (looking
at what point, if any, did alsa-lib start returning positive EFOO
values (e.g. EBUSY) rather than -EBUSY?
--p
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you
On Tue, 25 Nov 2003, Paul Davis wrote:
at what point, if any, did alsa-lib start returning positive EFOO
values (e.g. EBUSY) rather than -EBUSY?
I'm not aware. Which functions?
none. its OK, i was checking errno rather than the returned value. my
mistake. sorry for the distraction.
--p
I can't help you much, however, unless JACK has
recently been worked on I think there's a 32 track
limitation. It's known to be technically trivial.
still in place at this time. there is a simple 1-2 line solution; i'm
not sure if its the right one, since it simply substitutes a 64
channel
On Thu, 4 Dec 2003 06:41:56 -0800, Mark Knecht [EMAIL PROTECTED]=20
wrote:
Whenever I try to activate double speed (88.2/96kHz) mode with my RME
Hammerfall Lite (DIGI 9636), snd_pcm_hw_params fails with a 'Device or
resource busy' message. This is with the number of channels set to 10,
since
be overjoyed that was if and when it finally does. Don't expect anythin=
g
soon, unless you're willing to be that developer.
Actually, I'm not completely opposed to the idea. But I am totally=20
clueless when it comes to writing device drivers, and would have no idea=20
where to start. Do you
Actually, I'm not completely opposed to the idea. But I am totally
clueless when it comes to writing device drivers, and would have no
idea where to start.
Start here: http://www.alsa-project.org/documentation.php3#Driver
You don't have to start writing the driver from scratch. You only
have
I'd like to be able to query the capabilities (number of channels,=20
buffer
size etc.) of ALSA devices in the system, even if they should be in us=
e=20
by
some other process. The only current way to probe device capabilities =
is
to open a pcm, and use snd_pcm_hw_params, correct? At least
We all think in the same way, but there's no simple solution for this
problem. I prefer to have such configuration information in an user-space
database accessed via an alsa-lib API. It's nothing for the kernel space.
i'm not sure i agree with that. a user-space config DB could be used
to
I don't agree. The control API (usually) is for things that don't affect
the way data is transferred between the card the the computer.
it is *now*. i was just imagining a different conception of what it
could be used for.
Sample
I hope ALSA supports hardware features in certain sound cards (like hardware
mixing, sound buffer memory, and so on) like DirectSound does in Windows...
all that and a lot more.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Tim Goetze wrote:
* what kind(s) of sync-to-external will you need?
* do you want to receive/send MIDI sysex data?
last time i checked, the latter was impossible to do via the sequencer
API (please correct if things have changed).
Sending/receiving sysex has always been possible AFAIK. It's
I wanted to check my knowledge of something: does an xrun necessarily
correspond to a drop-out in the audio stream? In other words, could
you have a drop-out WITHOUT an xrun, or an xrun WITHOUT a drop-out? Is
there a strict one-to-one correspondence between the two?
a dropout occurs when the
My opinion is that a simple function could be included in alsactl which
scans for available devices, makes a list of their abilities. Everyone
uses post-insert alsactl restore in the modules.conf file so it would
be essentially a non issue from a user perspective.
i think it needs to be
Since there is almost nothing else to do to support the Aureal Vortex
3D processor on Linux, just as i announced some time ago i started
designing a OpenAL interface for ALSA. The design is meant to be
applicable to other hardware too.
I made a preliminary description, from what i have done so
i'm a bit late to the party, but ...
--- rme9652.c.ORIGINAL Thu Dec 18 23:43:36 2003
+++ rme9652.c Thu Dec 18 23:45:12 2003
@@ -1618,7 +1618,6 @@
RME9652_SPDIF_RATE(IEC958 Sample Rate, 0),
RME9652_ADAT_SYNC(ADAT1 Sync Check, 0, 0),
RME9652_ADAT_SYNC(ADAT2 Sync Check, 0,
Justin,
I'm running Alsa-1.0.0rc2. How much more up to date could I be?
Also, this is an HDSP 9652 which has the firmware on the board. Why
is a firmware loader required at all?
its not. jaroslav used that phrase because the bug manifested itself
most clearly when loading firmware. it was
i've been getting my laptop with an ICH soundchip up to speed, and i
just noticed for the first time yesterday that ALSA fails to get the
speed to the rate that JACK requests. a quick google reveals that the
OSS drivers only support 1 h/w rate, but there are suggestions that
the ALSA driver works
i've been getting my laptop with an ICH soundchip up to speed, and i
just noticed for the first time yesterday that ALSA fails to get the
speed to the rate that JACK requests. a quick google reveals that the
OSS drivers only support 1 h/w rate, but there are suggestions that
the ALSA driver works
yOn Sat, 27 Dec 2003, Paul Davis wrote:
i've been getting my laptop with an ICH soundchip up to speed, and i
just noticed for the first time yesterday that ALSA fails to get the
speed to the rate that JACK requests. a quick google reveals that the
OSS drivers only support 1 h/w rate
meanwhile, i have found that the plughw layer doesn't work with JACK
anymore. it appears that any attempt to set the period size fails. any
ideas about that?
to clarify: any attempt to set the period size if the SR is not 48kHz
will fail.
--p
We have been unable to find a way to tell ALSA, through
snd_pcm_mmap_begin(), where we want to write data when using the mmap
api. OSS doesn't have this restriction and this is the only documented
way we can see to support sound engines which mix in new sounds using
looping buffers and
although i agree that from a pragmatic perspective, it would be good
to understand how to use ALSA to do this.
however, this model of audio programming is not portable, and has
gotten people into trouble before, not just under Linux.
making the assumption that direct access at all times to the
That kind of argument would just corroborate the TransGaming report that
ALSA is no good overhead-wise, which is probably not what the ALSA
developers wish to do here.
i wasn't talking about ALSA. i was talking about audio hardware and
programming models in general. ALSA will allow pretty much
I'm working on changing DMIX to allow clients to open the capture stream.
i don't get it. dmix is for playback, not capture. what would be the
semantics of this?
--p
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an
However, trying to use either xmms, mplayer or mythtv with the same alsa
device just seems to leave the app hanging and not doing anything, and
attempts to fastforward in mplayer and mythtv (which presumably causes the
alsa layer in each app to try and pause then reopen the sound layer) causes
the
Using latest cvs I am unable to run the hdsp as a normal user. It works
as root user however.
Any ideas for fixing this?
more specifics about what doesn't work would be helpful.
---
This SF.net email is sponsored by: IBM Linux Tutorials.
I have application A that needs to open payback and capture streams
because it's a two-way communications program. Application B is a game
that uses playback only. I want to use these both at the same time.
but i don't think you can do this with OSS. why should ALSA's OSS
emulation make it
I have application A that needs to open payback and capture streams
because it's a two-way communications program. Application B is a game
that uses playback only. I want to use these both at the same time.
but i don't think you can do this with OSS. why should ALSA's OSS
emulation make
I am currently looking into rewriting our current OSS sound routines to nat
ive ALSA, as it seems OSS will invariably be phased out now that the ALSA driv
er is distrubuted with the Linux kernel, plus ALSA seems to have a great numbe
r of benefits for us.
Our current sound routines perform
it's not working on my system (i tried 64, 128, 256) ... but playing
then i guess there is more than one problem. i would also recommend
checking into whatever is sharing the interrupt that the hdsp is
on. on my laptop, way too many things are on IRQ10 (USB, CardBus,
Wifi, HDSP). this seems hard
Anyone using the latest RME HDSP 9632 driver in ALSA, while also using
the expansion cards? I mean, the newer AI4S-192 and/or AO4S-192 which
are required to get the 192kHz sampling on all analogs.
Do the latest expansion cards (192kHz) work with the latest ALSA driver?
i doubt it. RME have not
I have a few usability comments with regards to the drivers that I would
like to share, will draft a fuller email later, but basically I am using it
as a hifi input for music, nothing else, but I'm frequently getting very
jittery broken up audio (guessing that the default alsa buffer/latency
size
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 6
bInterfaceClass 255 Vendor Specific Class
^
i
I don't think so. If an sound app is swapped out or another app is doing
intensive disk IO we could observe - hear - the difference.
and how can OSS help with that? ok, so we know that non-SCHED_FIFO
apps (and occasionally, even them) can be delayed by kernel-side
issues. but not keeping up with
On Wed, Feb 25, 2004 at 09:17:54AM -0500, Paul Davis wrote:
There are only 2 differences associated with running the code you are
talking about in the kernel:
a) it runs deterministically in interrupt context
b) it avoids a context switch back into user space
It could be more
The ideal scheduler for realtime apps would be one that has an api that
allows for a call like schedule me at exactly 10ms intervals+-1ms.
no, thats not true.
the system clock does not run in sync with the sample clock. the drift
in this would become noticeable in a few minutes.
the only time
Taken for granted that configuration space on entry of function is not
empty
can this be taken for granted?
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps Web services for Linux with
a free DVD
Are you planning to standardize such features or design a
device-independent API for it? (And my manager wants to know which ALSA
release this might get implemented in...)
Just a thought on your overall issues with ALSA over the last week.
The kinds of features you seem to expect from hardware
And by that time, games will be even more demanding than before, and
still want to use those cycles for itself rather than software sound
processing, so just sitting idle waiting for the ultimate
infinite-megahertz cpu, that can do everything in no time, gains nobody
anything... at least our
In any case, most of this can all be handled by software. The only stuff
the hardware really need is the volume, frequency, direction to sound
source, and any additional effects (such as reverb). Application
software can deal with the rest.
i can certainly see the utility of such an API. however,
What I basically did is investigated the current driver in Windoze for the
carbus and it came up as a generic cardbus interface. I was by now aware
that the exact cardbus chipset is/was ENE C1410. So I did some searching on
the Google for the driver and came up with HP's driver download page for
Where can I get the complete list of controls which an audio codec has to
support.
there is no such list.
and lets get the terminology straightened out here before this goes
any further.
codec comes (in this context) from coder/decoder. that maps
roughly to what is more properly referred to
$ measure -p ./out/x11.png -o ./out/x11.out -c 0 -f 1024 -n 2 -t 2
I get this error message: error setting freq 1024
probably a permissions problem. try it as root.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial
open pcm, and get a handle.
snd_pcm_poll_descriptors(handle, pfd, err);
Get a poll file scriptor in pfd.
select(nfds, rfds, wfds, efds, tvp);
Is it possible to use this call with alsa ?
select is generally deprecated in linux (linus says so!). but you can
use the same pfds in select as in
open pcm, and get a handle.
snd_pcm_poll_descriptors(handle, pfd, err);
Get a poll file scriptor in pfd.
select(nfds, rfds, wfds, efds, tvp);
Is it possible to use this call with alsa ?
select is generally deprecated in linux (linus says so!). but you can
use the same pfds in
select is generally deprecated in linux (linus says so!). but you can
use the same pfds in select as in poll (select is implemented in the
kernel using the poll code). the problem is interpreting the results
you get back (as noted recently for the dmix plugin).
Nope, the application must give
The problem is that I cannot get the mixer to have any elements (or=20
elems as the alsamixer calls them) which thus makes the card un-openable=
=20
even with the alsamixer.
thats correct. the hdsp has no mixer that can be represented using
conventional mixer elements. there is nothing
mainly the alsa guys who wrote the driver and know, how they access the
bus system and the hardware, have to tell the pcmcia guys, who know,
what's going on in the bus ... i CC'd this mail to the thomas
charbonnel, paul davis and winfried ritsch, who wrote or maintain this
driver and the alsa
and it HAS do be a software issue, since at least on ico's and my
machine, the hdsp works flawless with winxp ...
agreed. but its much more likely to be something about the cardbus
support under linux than the hdsp driver, and neither side (the
cardbus people or us hdsp people) knows the other
I can't find any way to detect the running ALSA version, for diagnostic
cat /proc/asound/version
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo
Given that the alsa driv interrupts at period
boundaries(which are defined in bytes), the tests i
have carried out prove otherwise..i.e that the driver
operates in millisecond power-of-two based periods.
on most PCI-based hardware, the audio interface interrupts every N
audio frames, where N is
Well, if there is a way of monitoring these hex registers for various
hardware in Linux I could try to compare their state upon initialization in
Linux to that one in Windows (since in both situations they share the same
IRQ, at least on my notebook) and forward this info to you guys.
So my
Does this mean that now one can channel ALSA-only aware apps directly to JACK
Yes.
and if so, are there any penalties of doing it this way as oposed to using JAC
K-aware apps (i.e. Sample-sync?)?
Yes, you lose sample-synchronous guarantees. Also, there *might* be glitches
in the audio output
When using OSS you can just do mixer ioctl's on the opened PCM fd.
When using OSS, you can't model a lot of the functionality present in
contemporary audio interface hardware mixers.
So there's a choice: a limited, simple API that fails to support card
features, or a complex API that over time
Do you plan any driver for M-Audio Firewire Audiophile? I have contacted =
M-Audio=20
French Support and post this request, they told me that M-Audio driver te=
am=20
(USA) had request you for this card to have a driver under alsa. Can you =
confirm=20
that?
Please note: since NAMM this year,
in says under known bugs:
- 96kHz and 88.2kHz not accessible via PCM interface
What does that mean? The card and driver does work in 96 and 88.2 kHz, I
know that since I wrote the driver... but if there is some sort of bug,
I'd like to know.
anders, i don't know, but it might mean that you
Kernel people: is poll() less effective than using SND_PCM_ASYNC and a
signal handler for low-latency sound? I'm guessing it is, but there
at the risk of endlessly repeating myself, SIGIO is basically
useless. your handler executes in signal-handling context, and can do
very, very little. not
Hi ,
i'm trying to change the fragment size that the alsa
driver is capturing/playing out. It's currently set at
32 msecs(256 bytes).
They are set in the runtime structure...
runtime-period_max ...etc
Could anybody tell me which file these parameters are
set in the alsa-driver directory?
you
ok paul i had another look at the driver playback/capture tutorials. I have on
e question.Do applications initialize and use a pcm_handle of the alsa driver
when they begin interaction with it?Surely not
surely yes.
ALSA isn't structured the way windows seems to concieve of audio. We
don't
501 - 578 of 578 matches
Mail list logo
