3 Sep
2005
3 Sep
'05
9:35 a.m.
Hi,
I am an ALSA developer and I was wondering if there are any feature
requests that people who use this list would have.
I currently have a lot on my TODO list, but there is probably only one
feature on that list that might help you and that is dB level readouts
in alsamixer.
Currently, alsamixer uses a 0-100% readout, and on some sound cards 100%
is the 0dB level, and on others the 0dB level is around 80%.
This makes setting the capture levels rather difficult to get right in
Ardour. Most people would want the alsamixer capture volume controls to
all be set to 0dB and then let Ardour do any volume control.
Any other suggestions?
James
3 Sep
3 Sep
3:20 p.m.
On Sat, 2005-09-03 at 12:35 +0100, James Courtier-Dutton wrote:
Currently, alsamixer uses a 0-100% readout, and on
some sound cards 100%
is the 0dB level, and on others the 0dB level is around 80%.
Percent as volume scale is not very intuitive and is actually pretty
annoying. IMO, all volume adjustments should be in dB (or dBu or some
other commonly used unit). Thus you would know what the adjustment
really is, no matter what the current hardware supports.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
4:19 p.m.
On Saturday 03 September 2005 18:20, Jussi Laako wrote:
Percent as volume scale is not very intuitive and is
actually pretty
annoying. IMO, all volume adjustments should be in dB (or dBu or some
other commonly used unit). Thus you would know what the adjustment
really is, no matter what the current hardware supports.
db, as this is a gain change (which is unitless).
Regards, Dan.
6:14 p.m.
On Saturday 03 September 2005 20:30, Jussi Laako wrote:
On Sat, 2005-09-03 at 19:19 +0100, Dan Mills wrote:
It could also be calibrated, thus with unit.
I don't think this is right, a signal **level** can be measured against a
known reference level, and for metering it is important to know what this is,
but a **gain** value is **always** unitless (You are multiplying a signal
which has units by a scalar value).
Consider that +6db gain is double the amplitude at a signal LEVEL of -60dbu,
+40dbKW, or anything else, it is always double the amplitude (4* the power).
Note that some gear has for example switchable 'gain' of -10dbV or +4dbu, what
they actually mean is switchable reference level of....
Controls which switch the nominal reference level should be marked in terms of
what that reference IS, but general gain controls should be marked in just
db.
Meters should be referenced to some specified level (Ideally in terms of real
world voltages where analogue outputs are concerned), in the case of digital
outputs where the signal can only be referenced to full scale (whatever that
means), it is important to document any offsets. For example common UK
practice is to line up so that 0dbu = -20dbFS, now that is not your problem,
but if you are implementing a (say) VU meter, please document how many db
below 0dbFS your 0db mark is!
(Sorry, Hot button issue atm having spent far too much time trying to sort out
a problem with this stuff...).
Regards, Dan.
annoying.
IMO, all volume adjustments should be in dB (or dBu or some
db, as this is a gain change (which is unitless).
7 p.m.
Dan Mills wrote:
On Saturday 03 September 2005 20:30, Jussi Laako
wrote:
As far as I can tell, all sound cards volume controls are based around gain.
+dB for gain, and -dB for attenuation.
Examples of sound card hardware datasheets:
Record Volume control:
"The range is 12dB to -33dB in steps of 1.5dB."
I was planning to use the unit "dB" in the volume controls.
You seem to mention "db" but I see "dB" everywhere in the datasheets.
Are "db" and "dB" the same. If not, can someone please explain the
difference, as "db" seems more important to people here.
James
On Sat, 2005-09-03 at 19:19 +0100, Dan Mills
wrote:
It could also be calibrated, thus with unit.
I don't think this is right, a signal **level** can be measured against a
known reference level, and for metering it is important to know what this is,
but a **gain** value is **always** unitless (You are multiplying a signal
which has units by a scalar value).
Consider that +6db gain is double the amplitude at a signal LEVEL of -60dbu,
+40dbKW, or anything else, it is always double the amplitude (4* the power).
Note that some gear has for example switchable 'gain' of -10dbV or +4dbu, what
they actually mean is switchable reference level of....
Controls which switch the nominal reference level should be marked in terms of
what that reference IS, but general gain controls should be marked in just
db.
Meters should be referenced to some specified level (Ideally in terms of real
world voltages where analogue outputs are concerned), in the case of digital
outputs where the signal can only be referenced to full scale (whatever that
means), it is important to document any offsets. For example common UK
practice is to line up so that 0dbu = -20dbFS, now that is not your problem,
but if you are implementing a (say) VU meter, please document how many db
below 0dbFS your 0db mark is!
(Sorry, Hot button issue atm having spent far too much time trying to sort out
a problem with this stuff...).
Regards, Dan.
annoying.
IMO, all volume adjustments should be in dB (or dBu or some
db, as this is a gain change (which is unitless).
10:55 p.m.
On Saturday 03 September 2005 22:00, James Courtier-Dutton wrote:
As far as I can tell, all sound cards volume controls
are based around
gain. +dB for gain, and -dB for attenuation.
Examples of sound card hardware datasheets:
Record Volume control:
"The range is 12dB to -33dB in steps of 1.5dB."
I was planning to use the unit "dB" in the volume controls.
That is exactly as it should be, it was the notion of expressing gain as dBu
(or dbu) that I was objecting to....
You seem to mention "db" but I see "dB" everywhere in the
datasheets.
Are "db" and "dB" the same. If not, can someone please explain the
difference, as "db" seems more important to people here.
It just depends on if you consider the Bell in question to be a proper noun!
dB is probably correct, I was just being lazy.
On Nice features, How about a helper function in the library to convert given
number of blocks of samples as say floats into the correct buffer format to
pass to the soundcard? It would cut lot a lot of (paraphrasing):
if (snd_format = INTERLEAVED)
.
.
.
else if (snd_format == NON_INTERLEAVED)
.
.
.
else if (....)
which is both hard to debug without all the funky hardware out there, and
repeated in **LOTS** of ALSA applications.
Also there be lots of dragons with things like the ICE1712 taking 32 bit
samples and only using the UPPER 24 bits!
IMHO Alsa lib at present does a poor job of hiding the scary hardware details
of this stuff from those applications which don't care. Sure it provides
plenty of functionality for Jack and friends which need to know about this
stuff, but many apps don't need to know about the memory layout of the buffer
and would be happy in blissful ignorance.
I suggested float as the input format but int would serve as well as long as
the maximum sample value supported by the card was easy to discover.
Ohh yea, a similar function to unpack the card buffer back into individual
streams would also be nice.
Just a thought.
Regards, Dan (I know, just use jack and be happy...).
11:20 p.m.
On Sun, 2005-09-04 at 01:55 +0100, Dan Mills wrote:
On Nice features, How about a helper function in the
library to
convert given
number of blocks of samples as say floats into the correct buffer
format to
pass to the soundcard? It would cut lot a lot of (paraphrasing):
if (snd_format = INTERLEAVED)
.
.
.
else if (snd_format == NON_INTERLEAVED)
.
.
.
else if (....)
The ALSA plug layer already handles the case where the app can only play
interleaved and the hardware can only do noninterleaved.
I suspect the above is so common because people just copy the example
programs that come with alsa-lib.
Lee
4 Sep
4 Sep
7:59 a.m.
Dan Mills wrote:
On Nice features, How about a helper function in the
library to convert given
number of blocks of samples as say floats into the correct buffer format to
pass to the soundcard? It would cut lot a lot of (paraphrasing):
if (snd_format = INTERLEAVED)
.
.
.
else if (snd_format == NON_INTERLEAVED)
.
.
.
else if (....)
which is both hard to debug without all the funky hardware out there, and
repeated in **LOTS** of ALSA applications.
Also there be lots of dragons with things like the ICE1712 taking 32 bit
samples and only using the UPPER 24 bits!
IMHO Alsa lib at present does a poor job of hiding the scary hardware details
of this stuff from those applications which don't care. Sure it provides
plenty of functionality for Jack and friends which need to know about this
stuff, but many apps don't need to know about the memory layout of the buffer
and would be happy in blissful ignorance.
I suggested float as the input format but int would serve as well as long as
the maximum sample value supported by the card was easy to discover.
Ohh yea, a similar function to unpack the card buffer back into individual
streams would also be nice.
Just a thought.
Regards, Dan (I know, just use jack and be happy...).
Applications should not really be using ALSA device names like "hw:0,0"
"hw:0,1" etc. They should be using "front", "rear" etc.
In addition to that there is a "plug" layer which is used if one opens
the ALSA device with "plug:front", "plug:rear" etc.
This plug layer then lets the application use whichever sound format
they wish to use and send it to ALSA. ALSA will then convert it to
whichever format the hardware can handle and then send it to the card.
So, using this method, no "helpers" are needed in the application.
There are also some extra api calls to modify how the "plug" layer acts.
By default, the plug layer will do resampling, sample format conversion
etc. The ALSA resampler is not great, and the fix for that is in fact
rather complicated so no-one has had the time to complete it. But, one
extra api can specifically turn this "plug" feature off, so the
application can then find out which sample rates the sound card can do
in hardware, and then let the application handle the samplerate
conversion. Much higher quality sample rate conversion is possible at
the application layer.
So, I would say that ALSA does an extremely good job of hiding the
hardware details from the user, but application have not all caught on
to that fact yet.
James
5 Sep
5 Sep
5:37 a.m.
Dan Mills wrote:
On Saturday 03 September 2005 22:00, James
Courtier-Dutton wrote:
With "Alexander Graham" in front, it certainly is.
HTH
Clemens
You seem to mention "db" but I see
"dB" everywhere in the datasheets.
Are "db" and "dB" the same. If not, can someone please explain the
difference, as "db" seems more important to people here.
It just depends on if you consider the Bell in question to be a proper noun! 
7:41 a.m.
On Mon, 2005-09-05 at 09:37 +0200, Clemens Ladisch wrote:
Dan Mills wrote:
wikipedia says:
The d is lowercase, as it is the SI prefix deci-, and the B is
capitalized, as it is an abbreviation of a name-derived unit, the bel,
named for Alexander Graham Bell. Written out it becomes decibel.
On Saturday 03 September 2005 22:00, James
Courtier-Dutton wrote:
With "Alexander Graham" in front, it certainly is. You seem to mention "db" but I see
"dB" everywhere in the datasheets.
Are "db" and "dB" the same. If not, can someone please explain the
difference, as "db" seems more important to people here.
It just depends on if you consider the Bell in question to be a proper noun!
HTH
Clemens
--
4 Sep
4 Sep
7:12 p.m.
On Sat, 2005-09-03 at 21:14 +0100, Dan Mills wrote:
I don't think this is right, a signal **level**
can be measured against a
known reference level, and for metering it is important to know what this is,
but a **gain** value is **always** unitless (You are multiplying a signal
which has units by a scalar value).
The thing here, is that I would like to know which actual output level
results when some given sample value is written with some gain setting.
Or I could determine actual input level by reading sample value and
input gain setting.
Now, if the mixer adjustment is just 0-100% of unspecified gain range,
this is rather hard. If it's in dB, it is possible if there is some
relation of the gain with some actual level. ie. 0 dB gain would mean x
dBu output level.
For example, with some industrial A/D and D/A card's I'm able to
calculate actual sound pressure at microphone when it's sensitivity vs.
frequency is known. Or to know how to get exactly 1Vpp output level.
With my M-Audio Delta1010 this is rather easy, as there are no
adjustable analog gain stages and it can be calibrated. But trying to do
this generally with any sound card is pretty hard.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
8:34 p.m.
On Sunday 04 September 2005 22:12, Jussi Laako wrote:
On Sat, 2005-09-03 at 21:14 +0100, Dan Mills wrote:
Indeed!
The good stuff typically documents (for example) an analogue output level of
+4dBu for a sample 16db below full scale (or equivalently) that zero dBfs is
+20dBu. Note that the reconstruction filter overshoot will actually put the
peak output level up around +22dBu in this case!
With pro hardware that does not have integrated 'gain' controls (or at least
calibrates them), this is easy, otherwise an audio milivoltmeter (or 'scope)
and a simple program is required.
Regards, Dan.
I don't think this is right, a signal
**level** can be measured against a
known reference level, and for metering it is important to know what this
is, but a **gain** value is **always** unitless (You are multiplying a
signal which has units by a scalar value).
The thing here, is that I would like to know which actual output level
results when some given sample value is written with some gain setting.
Or I could determine actual input level by reading sample value and
input gain setting.
5 Sep
5 Sep
3:59 a.m.
On Sun, 2005-09-04 at 23:34 +0100, Dan Mills wrote:
With pro hardware that does not have integrated
'gain' controls (or at least
calibrates them), this is easy, otherwise an audio milivoltmeter (or 'scope)
and a simple program is required.
I think this calibration should already have been done in each driver.
This is something rather easy to do while developing the driver. And
from application point of view, there should be way to know how the gain
relates to actual output level. ie. know what the "0 dB" level is.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
9:18 p.m.
Lee Revell wrote:
On Sat, 2005-09-03 at 12:35 +0100, James
Courtier-Dutton wrote:
What is the reason for this need?
Do some emu10k1 cards have the outputs swapped so they appear wrong?
If it is due to hardware differences, we could make allowances in the
driver and not need a "swap ..." control.
James
Any other suggestions?
A "Swap Front and Rear" control for the emu10k1.
Lee
9:36 p.m.
On Sun, 2005-09-04 at 00:18 +0100, James Courtier-Dutton wrote:
Lee Revell wrote:
The I2S codec used for the rear channels is of much higher quality than
the AC97 codec used for front and center/LFE.
It's in the kX driver FAQ.
Lee
On Sat, 2005-09-03 at 12:35 +0100, James
Courtier-Dutton wrote:
What is the reason for this need?
Do some emu10k1 cards have the outputs swapped so they appear wrong?
If it is due to hardware differences, we could make allowances in the
driver and not need a "swap ..." control. Any other suggestions?
A "Swap Front and Rear" control for the emu10k1.
Lee
4 Sep
4 Sep
7:50 a.m.
Lee Revell wrote:
On Sun, 2005-09-04 at 00:18 +0100, James
Courtier-Dutton wrote:
Can you please post the output of:
lspci -vvn | grep -1 0401
What you say above is certainly not valid for all SB Live, Audigy and
Audigy 2 sound cards. The snd-emu10k1 driver works for all those.
On all the Audigy 2's I have seen, it uses I2S for all outputs.
James
Lee Revell wrote:
The I2S codec used for the rear channels is of much higher quality than
the AC97 codec used for front and center/LFE.
It's in the kX driver FAQ.
Lee
On Sat, 2005-09-03 at 12:35 +0100, James
Courtier-Dutton wrote:
What is the reason for this need?
Do some emu10k1 cards have the outputs swapped so they appear wrong?
If it is due to hardware differences, we could make allowances in the
driver and not need a "swap ..." control. Any other suggestions?
A "Swap Front and Rear" control for the emu10k1.
Lee
8:13 a.m.
On Sun, 2005-09-04 at 10:50 +0100, James Courtier-Dutton wrote:
What you say above is certainly not valid for all SB
Live, Audigy and
Audigy 2 sound cards. The snd-emu10k1 driver works for all those.
I think this might only apply to SBLives and not Audigy/Audigy2. Still,
it's harmless if the front and rear codecs are of similar quality. And
there are definitely a lot of cards where the rear codec is better.
Many of the people who request it dual boot and use the kX driver under
Windows so jsut don't want to have to switch their speaker cables
around.
Lee
8:40 a.m.
Lee Revell wrote:
On Sun, 2005-09-04 at 10:50 +0100, James
Courtier-Dutton wrote:
If users are switching their cables around and can actually hear the
difference, then I suggest they just edit their .asoundrc file to do the
switch for them. No need to change any of ALSA.
James
What you say above is certainly not valid for all
SB Live, Audigy and
Audigy 2 sound cards. The snd-emu10k1 driver works for all those.
I think this might only apply to SBLives and not Audigy/Audigy2. Still,
it's harmless if the front and rear codecs are of similar quality. And
there are definitely a lot of cards where the rear codec is better.
Many of the people who request it dual boot and use the kX driver under
Windows so jsut don't want to have to switch their speaker cables
around.
Lee
8:59 a.m.
On Sun, 2005-09-04 at 11:40 +0100, James Courtier-Dutton wrote:
If users are switching their cables around and can
actually hear the
difference, then I suggest they just edit their .asoundrc file to do the
switch for them. No need to change any of ALSA.
I suggested that first to Takashi and he said "do it in the driver".
Lee
4 Sep
4 Sep
8:48 a.m.
Tim Goetze wrote:
[James Courtier-Dutton]
Yes, that's certainly nice to have. :-)
If you only knew how exceptionally hard that is to actually achieve. :-(
There is currently work to achieve this for the Audigy 2 sound card,
hopefully support for that will follow for other sound cards.
What sort of API would you like?
One suggested is where one opens the PCM channel in order to write
samples to it, and then uses the opened handle to talk to the mixer
controls.
Any other suggestions?
A provision for reliably identifying the mixer control(s) belonging to
a given open PCM channel would be very nice to have.
Cheers, Tim
7:41 p.m.
[James Courtier-Dutton]
Tim Goetze wrote:
A provision for reliably identifying the mixer
control(s) belonging to a given
open PCM channel would be very nice to have.
Cheers, Tim
Yes, that's certainly nice to have. :-)
If you only knew how exceptionally hard that is to actually achieve. :-( From my days of poking around alsa-lib and -driver
sources back when
the ice1712 driver wouldn't support the audiophile out of the
box, I
seem to remember ... yes, it seemed hard then already, and maybe even
more so with drivers capable of dynamic channel assignment, like
snd-via82xx on this box.
There is currently work to achieve this for the Audigy
2 sound card, hopefully
support for that will follow for other sound cards.
What sort of API would you like?
One suggested is where one opens the PCM channel in order to write samples to
it, and then uses the opened handle to talk to the mixer controls.
As far as I remember, I would have liked to give alsa-lib my handle to
the PCM device and the channel number and use that to start an
enumeration of the respective mixer controls.
If I'm not mistaken (it's been awhile and unfortunately current API
docs aren't readily available to me) that would be enough since the
type of a control -- gain, balance, eq or whatever -- is communicated
along with the mixer control id or can easily be queried.
As you suggest, this seems unnecessary for inbound sample streams but
I won't venture to claim that's definite.
Cheers, Tim
3 Sep
3 Sep
8:44 p.m.
On Sat, 2005-09-03 at 12:35 +0100, James Courtier-Dutton wrote:
Hi,
I am an ALSA developer and I was wondering if there are any feature
requests that people who use this list would have.
I currently have a lot on my TODO list, but there is probably only one
feature on that list that might help you and that is dB level readouts
in alsamixer.
Currently, alsamixer uses a 0-100% readout, and on some sound cards 100%
is the 0dB level, and on others the 0dB level is around 80%.
Are you saying that some soundcards saturates at 0db (100%) where as
others leaves 12db headroom (having 0db == 80%)
If I had my way, I would prefer all souncards to be of the headroom
variety ... as a standard. You can always push volume up and beyond,
should need arise.
This makes setting the capture levels rather difficult to get right in
Ardour. Most people would want the alsamixer capture volume controls to
all be set to 0dB and then let Ardour do any volume control.
Any other suggestions?
Nothing special except for the obvious limiter upfront before you start
sampling.
James
--
4 Sep
4 Sep
9:14 a.m.
Jens M Andreasen wrote:
Jens,
What do you mean by "limiter upfront". I am not an audio mixer studio
expert. Is this something for the detection of clipping in the audio
path? If so, I am afraid that I don't know of any sound card hardware
that has that feature.
Too me, a limiter would be something that limits the max peaks of a
signal. For playback, one could use the application to do the limiting
and set the sound card for 0dB so that no extra clipping happened in the
output path, but for capture it is more difficult. The limiter should
really be in the pre-amp prior to the ADC. Once the signal is digital,
one can set all the sound cards digital mixers to 0dB and then just pass
it to the application knowing that no further clipping or quality loss
has happened.
With a better understanding of the capture path on the sound card.
e.g. Pre-amp(gain controlled) -> ADC -> Digital mixer -> PCM.
One could implement some basic limiting by letting the application
detect any digital sample getting close to the limit and controlling the
Pre-amp gain control as a result. In this example, one would want the
"Digital mixer" to be set to 0dB so that the samples reaching the PCM
were exactly the same as the samples leaving the ADC.
So, one step to achieve this would be to clearly identify all the
alsamixer controls that control the analog "Pre-amp" parts before the ADC.
In any case, the first step to achieving all this is to get alsamixer to
show dB gain instead of %
James
Any other suggestions?
Nothing special except for the obvious limiter upfront before you start
sampling.
3 Sep
3 Sep
9:21 p.m.
James Courtier-Dutton <James(a)superbug.co.uk> writes:
any feature requests that people who use this list
would have.
Fixing plug:jack. As of current, it does not work with devices that
read and write to the device at the same time, such as voip
applications.
In my case I use asterisk.
I've opened a bug on this issue:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1324
The package alsa-plugins, which has the plug:jack code just went from
1.0.9 to 1.0.10rc1 without a single code change to the pcm_jack.c
file, so that was a little sad;)
Any other suggestions?
Implement alsamixer as a daemon and add osc support, then make it work
with rme devices not currently usable with alsamixer, such as the
multiface.;)
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
9:38 p.m.
On Sun, 2005-09-04 at 03:21 +0200, Esben Stien wrote:
Implement alsamixer as a daemon and add osc support,
then make it work
with rme devices not currently usable with alsamixer, such as the
multiface.;)
I'd rather see the ALSA mixer API become powerful enough to handle all
these devices that currently need hardware specific mixer apps.
Lee
10:45 p.m.
Lee Revell <rlrevell(a)joe-job.com> writes:
I'd rather see the ALSA mixer API become powerful
enough to handle
all these devices that currently need hardware specific mixer apps.
Yes, definitely.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
4 Sep
4 Sep
8:28 a.m.
Esben Stien wrote:
James Courtier-Dutton <James(a)superbug.co.uk>
writes:
VoIP application should really be opening the ALSA device twice, once
for playback and once for capture. The reason for this is that a lot of
sound cards have different buffer sizes for capture and playback and the
only way to have proper control over these is to open them separately.
There is also the matter of sound routing. If you just opened it once
for full duplex, how could you select which mic and which speakers the
sound will come from. By opening each channel separately, one can decide
to route the sound to the correct place. E.g. playback device could be
"plug:front" or "plug:rear" and the capture device could be
"default"
I know for a fact that all Creative sound cards will fail VoIP apps if
they are opened with a single device in full-duplex, but work fine if
two devices are opened, one for capture, and one for playback.
It is my advice to fix the VoIP apps instead.
any feature requests that people who use this list
would have.
Fixing plug:jack. As of current, it does not work with devices that
read and write to the device at the same time, such as voip
applications.
In my case I use asterisk.
I've opened a bug on this issue:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1324
Sorry, I cannot help you with this problem. I don't work on the jack
bits of ALSA. I don't actually use jack or Ardour much. I have installed
Ardour in order to find out just how difficult it is to use unless you
can get the gain levels correct in alsamixer, and having alsamixer
currently doing just % measurements makes it next to impossible to get
right unless one looks in the alsa source code and the appropriate data
sheets. It is this reason why I am aiming to work on converting the
alsamixer to display where the 0dB gain/attenuation point is, so that
the Ardour application can then know that the sound card will pass the
sound in and out of Ardour without modifying it.
The package alsa-plugins, which has the plug:jack code just went from
1.0.9 to 1.0.10rc1 without a single code change to the pcm_jack.c
file, so that was a little sad;)
alsamixer is already like daemon. One can connect as many mixer control
apps as one likes to the alsa mixer control api.
OSC to me seems like just another network audio method. Does OSC include
a mixer api? ALSA currently only intends to handle sound cards. I would
have thought that jack should just write another module to talk to OSC,
much like jack currently talks to ALSA. I don't see why ALSA should
support OSC.
Any other suggestions?
Implement alsamixer as a daemon and add osc support, then make it work
with rme devices not currently usable with alsamixer, such as the
multiface.;)
6:39 p.m.
James Courtier-Dutton <James(a)superbug.co.uk> writes:
VoIP application should really be opening the ALSA
device twice
It does. From the alsa.conf (asterisk) config file:
..for alsa:
input_device=hw:0,0
output_device=hw:0,0
..for jack:
input_device=plug:jack
output_device=plug:jack
Alsa works, but not plug:jack, which was explained in the bug report.
I know for a fact that all Creative sound cards will
fail VoIP apps
if they are opened with a single device in full-duplex
I have a emu10k1 based cards and I've never had any problems with any
voip app (asterisk, kphone, iaxcomm) when using alsa, so I guess all
of them don't open a single device in duplex.
It is my advice to fix the VoIP apps instead.
Well, not the case here;).
I don't see why ALSA should support OSC.
No, this was just related to the alsa API not supporting all devices,
such as the multiface.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
7063
days inactive
7065
days old
linux-audio-dev@lists.linuxaudio.org
30 comments
8 participants
participants (8)
-
Clemens Ladisch -
Dan Mills -
Esben Stien -
James Courtier-Dutton -
Jens M Andreasen -
Jussi Laako -
Lee Revell -
Tim Goetze