15 Jun
2005
15 Jun
'05
11:31 a.m.
Hi.
Since I finally ordered my Multiface, I also started to write
a small program which I am going to need since hdspconf and hdspmixer
are both GUI only.
The idea:
hdsposc will offer the RME mixer and the metering functionality
via OSC.
Why do I write this mail? I'd like to know if someone else
could also make use of this tool. If so, I'd like to hear
your input what you'd want to exactly do with it. If no one responds,
I'll save coding time by ONLY implementing the Multiface (since thats
what I can test) and probably not polish it much, since
what I need is probably very basic.
Oh, and BTW, during coding of hdsposc a question arose:
Is it recommended practice to immediately close a hwdep device
again after performing a single operation, or would it be OK
to leave the hwdep handle open during runtime and only close it
again on program shutdown?
--
CYa,
Mario
15 Jun
15 Jun
1:26 p.m.
Hi.
Since I finally ordered my Multiface, I also started to write
a small program which I am going to need since hdspconf and hdspmixer
are both GUI only.
The idea:
hdsposc will offer the RME mixer and the metering functionality
via OSC.
Why do I write this mail? I'd like to know if someone else
could also make use of this tool. If so, I'd like to hear
your input what you'd want to exactly do with it. If no one responds,
I'll save coding time by ONLY implementing the Multiface (since thats
what I can test) and probably not polish it much, since
what I need is probably very basic.
Oh, and BTW, during coding of hdsposc a question arose:
Is it recommended practice to immediately close a hwdep device
again after performing a single operation, or would it be OK
to leave the hwdep handle open during runtime and only close it
again on program shutdown?
Hi Mario !
This is great. Doing this has been part of my plan for the hdsp for a
long time, but it's been delayed and delayed, and I have to admit that
there is nearly no chance that I could find time to work on this in the
next months.
I'll explain here what I had in mind with the avowed hope to push you in
this direction as I believe this is the way to go :)
Situation :
The hdsp is a great piece of hardware, and very straightforward to
handle as almost everything is done in hardware. The alsa ctls the
driver exports reflect this. But now comes the problem : if you ever
used totalmix/hdspmixer, you probably used the last row (Output row).
It is very useful, but here's how it works: every time you manipulate
this row, hdspmixer/totalmix has to calculate and apply the attenuation
coefficient to all streams routed to the specific physical output you
targeted. Why is this a problem ? Because there is some information in
hdspmixer that is not present in the hardware, and gets lost when
hdspmixer is no more available. Also this prevents different application
to access the mixer at the same time and share a common representation.
If you play with amixer and the mixer ctl while hdspmixer is running,
you'll invalidate hdspmixer's representation. And of course you can't
use the very nice alsa monitoring/callback mechanism on ctls.
So what can we do ?
Implement a daemon to hold this representation and share it with other
apps through OSC. Then rewrite the hdsp* tools to optionally use the osc
backend instead of talking directly to the card using ctls.
What are the benefits and possibilities ?
* can you imagine controlling a farm of hdsp powered machine with
hdspmixer and hdspconf running on a (possibly) hdsp-less machine on the
network ?
* have a pd or sc patch, or a ladspa plugin (automated in ardour ? :)
control the card's mixer and visualise the changes with hdspmixer (or
the opposite)
* implement a ramping mechanism in the daemon to eliminate zipper noises
when accessing the mixer, thus making the hw mixer usable in live
conditions.
* provide fake standard mixer ctls in the driver, like a "master volume"
ctl for example. The ctl does nothing in kernel space, but the daemon
has a callback registered on it and does the actual job when for example
the gnome mixer applet requests a change. (and again all this can be
visualised in hdspmixer).
I hope all this was more exciting than confusing,
Thomas
2:33 p.m.
thomas charbonnel <thomas(a)undata.org> writes:
Great, I already kind of hoped you'd take the idea that way. All arguments
below aside, its the code duplication alone that really bugs me.
Hi.
Since I finally ordered my Multiface, I also started to write
a small program which I am going to need since hdspconf and hdspmixer
are both GUI only.
The idea:
hdsposc will offer the RME mixer and the metering functionality
via OSC.
Why do I write this mail? I'd like to know if someone else
could also make use of this tool. If so, I'd like to hear
your input what you'd want to exactly do with it. If no one responds,
I'll save coding time by ONLY implementing the Multiface (since thats
what I can test) and probably not polish it much, since
what I need is probably very basic.
Oh, and BTW, during coding of hdsposc a question arose:
Is it recommended practice to immediately close a hwdep device
again after performing a single operation, or would it be OK
to leave the hwdep handle open during runtime and only close it
again on program shutdown?
Hi Mario !
This is great. Doing this has been part of my plan for the hdsp for a
long time, but it's been delayed and delayed, and I have to
admit that there is
nearly no chance that I could find time to work on this in the next
months.
I'll explain here what I had in mind with the avowed hope to push you in
this direction as I believe this is the way to go :)
Situation :
The hdsp is a great piece of hardware, and very straightforward to
handle as almost everything is done in hardware. The alsa ctls the
driver exports reflect this. But now comes the problem : if you ever
used totalmix/hdspmixer, you probably used the last row (Output row).
It is very useful, but here's how it works: every time you manipulate
this row, hdspmixer/totalmix has to calculate and apply the attenuation
coefficient to all streams routed to the specific physical output you
targeted. Why is this a problem ? Because there is some information in
hdspmixer that is not present in the hardware, and gets lost when
hdspmixer is no more available.
I am not sure that I really understand. There is a hwdep ioctl to
receive the cuttent mixer matrix, wouldnt that kind of suffice to reconstruct
the gui? Or am I completely missing something else here? Mind my
situation, I have not use hdspmixer before, since I cant actually see its output.
So I have learned from the code, mostly.
Also this prevents different application to access the
mixer at the
same time and share a common representation. If you play with
amixer and the mixer ctl while hdspmixer is running, you'll
invalidate hdspmixer's representation. And of course you can't use
the very nice alsa monitoring/callback mechanism on ctls.
So what can we do ?
Implement a daemon to hold this representation and share it with other
apps through OSC. Then rewrite the hdsp* tools to optionally use the osc
backend instead of talking directly to the card using ctls.
I'd prefer if the GUI frontends would be made frontends only, to eliminate
the duplicated code. But thats already very futuristic... :)
What are the benefits and possibilities ?
* can you imagine controlling a farm of hdsp powered machine with
hdspmixer and hdspconf running on a (possibly) hdsp-less machine on the
network ?
Sure :-)
* have a pd or sc patch, or a ladspa plugin (automated
in ardour ? :)
control the card's mixer and visualise the changes with hdspmixer (or
the opposite)
hdsposc already contains a prototype of a HDSP class for SC :-)
It doesnt do much more than measuring latency with a ping right now, but hey :-)
* implement a ramping mechanism in the daemon to
eliminate zipper noises
when accessing the mixer, thus making the hw mixer usable in live
conditions.
Hmm, lagtime, neat idea.
* provide fake standard mixer ctls in the driver, like
a "master volume"
ctl for example. The ctl does nothing in kernel space, but the daemon
has a callback registered on it and does the actual job when for example
the gnome mixer applet requests a change. (and again all this can be
visualised in hdspmixer).
That definitely goes over my capabilities regarding alsa
hackage...
I hope all this was more exciting than confusing,
Thomas
I guess for now, I'll keep it simple, maybe someone can later take it
and work on from there to complete the whole task. My problem is basically
that I cant see the current GUIs, and it sounds like very hard work to
work out the complete underlying model from just reading (C++, eeeek!)
code.
--
CYa,
Mario
16 Jun
16 Jun
6:41 a.m.
Mario Lang wrote :
(...)
There shouldn't be any code duplication, hopefully.
It's not extremely easy to describe, but I think the main point is this:
think of the output row as an additional attenuation stage. I can ask
the app to apply a -10dB attenuation on all signals routed to the
physical output 1 for example. Internally it translates to (multiple)
standard mixer calls. The problem is that the same hardware mixer state,
as kept in the driver and hardware, can be translated to different
hdspmixer states. For example in the case the hardware mixer says input
1 should be routed to output 1 with a 6dB attenuation, this could have
been generated by a hdspmixer configuration were the input is routed to
the output with no attenuation but there is a 6dB global attenuation on
this output. So the whole thing is like a set of per-physical-output
master volume controls. To use your app as a backend for hdspmixer, this
additional logic has to be implemented.
That's what I meant, roughly. What we could also do is have some form of
library that would encapsulate all this (notably the OSC code and
callbacks) and expose a simple hdsp specific api. And as far as the
daemon is concerned most of the ctl code and app logic could be directly
ripped off hdspmixer.
Nice !
This has often been requested by users. It's very easily done once the
daemon is here.
On the model side, it's quite easy : everything seems to work as the
mixer ctl (input/playback, output, gain) except the backend applies this
last per-physical-output attenuation before actually setting the
hardware. So you just need an extra call to set or retrieve the
attenuation for a given output, and you have to keep the state of the
matrix (which is now disconnected from the hardware matrix), and the
per-output state of the attenuation stage.
Last point: I'm absolutely willing to contribute to this, as much as I
can, notably on the driver/tools side.
Thomas
This is great. Doing this has been part of my plan for the hdsp for a
long time,
Great, I already kind of hoped you'd take the idea that way. All arguments
below aside, its the code duplication alone that really bugs me.
but it's
been delayed and delayed, and I have to admit that there is
nearly no chance that I could find time to work on this in the next
months.
I'll explain here what I had in mind with the avowed hope to push you in
this direction as I believe this is the way to go :)
Situation :
The hdsp is a great piece of hardware, and very straightforward to
handle as almost everything is done in hardware. The alsa ctls the
driver exports reflect this. But now comes the problem : if you ever
used totalmix/hdspmixer, you probably used the last row (Output row).
It is very useful, but here's how it works: every time you manipulate
this row, hdspmixer/totalmix has to calculate and apply the attenuation
coefficient to all streams routed to the specific physical output you
targeted. Why is this a problem ? Because there is some information in
hdspmixer that is not present in the hardware, and gets lost when
hdspmixer is no more available.
I am not sure that I really understand. There is a hwdep ioctl to
receive the cuttent mixer matrix, wouldnt that kind of suffice to reconstruct
the gui? Or am I completely missing something else here? Mind my
situation, I have not use hdspmixer before, since I cant actually see its output.
So I have learned from the code, mostly.
Also this
prevents different application to access the mixer at the
same time and share a common representation. If you play with
amixer and the mixer ctl while hdspmixer is running, you'll
invalidate hdspmixer's representation. And of course you can't use
the very nice alsa monitoring/callback mechanism on ctls.
So what can we do ?
Implement a daemon to hold this representation and share it with other
apps through OSC. Then rewrite the hdsp* tools to optionally use the osc
backend instead of talking directly to the card using ctls.
I'd prefer if the GUI frontends would be made frontends only, to eliminate
the duplicated code. But thats already very futuristic... :)
What are the
benefits and possibilities ?
* can you imagine controlling a farm of hdsp powered machine with
hdspmixer and hdspconf running on a (possibly) hdsp-less machine on the
network ?
Sure :-)
* have a pd or sc patch, or a ladspa plugin
(automated in ardour ? :)
control the card's mixer and visualise the changes with hdspmixer (or
the opposite)
hdsposc already contains a prototype of a HDSP class for SC :-)
It doesnt do much more than measuring latency with a ping right now, but hey :-) * implement a
ramping mechanism in the daemon to eliminate zipper noises
when accessing the mixer, thus making the hw mixer usable in live
conditions.
Hmm, lagtime, neat idea.
* provide fake standard mixer ctls in the driver,
like a "master volume"
ctl for example. The ctl does nothing in kernel space, but the daemon
has a callback registered on it and does the actual job when for example
the gnome mixer applet requests a change. (and again all this can be
visualised in hdspmixer).
That definitely goes over my capabilities regarding alsa
hackage...
I hope all this was more exciting than confusing,
Thomas
I guess for now, I'll keep it simple, maybe someone can later take it
and work on from there to complete the whole task. My problem is basically
that I cant see the current GUIs, and it sounds like very hard work to
work out the complete underlying model from just reading (C++, eeeek!)
code.
15 Jun
15 Jun
3:51 p.m.
On Wednesday 15 June 2005 15:32, Mario Lang wrote:
The idea:
hdsposc will offer the RME mixer and the metering functionality
via OSC.
Regardless wether it becomes a separate programm or gets included into
hdspconf, can you publish the osc-Interface structure?
I am currently working on osc-support in JackMix and am wondering which
interface structure to use. I want to separate the GUI from the mixer-app and
connect them via osc and in this step I could make it compatible to hdsposc
so JackMix could be used as a GUI for it...
Arnold
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
20 Jun
20 Jun
1:19 p.m.
Hi, Mario:
Mario Lang writes:
Hi.
Since I finally ordered my Multiface, I also started to write
a small program which I am going to need since hdspconf and hdspmixer
are both GUI only.
The idea:
hdsposc will offer the RME mixer and the metering functionality
via OSC.
Why do I write this mail? I'd like to know if someone else
could also make use of this tool. If so, I'd like to hear
your input what you'd want to exactly do with it. If no one responds,
I'll save coding time by ONLY implementing the Multiface (since thats
what I can test) and probably not polish it much, since
what I need is probably very basic.
I would use this. Thank you.
I also have nothing to add at this point in terms of feature requests.
At the moment I have a Multiface only.
Are you contemplating a ncurses type u-i? Emacs? CLI?
Janina
Oh, and BTW, during coding of hdsposc a question arose:
Is it recommended practice to immediately close a hwdep device
again after performing a single operation, or would it be OK
to leave the hwdep handle open during runtime and only close it
again on program shutdown?
--
CYa,
Mario
--
Chair, Accessibility Workgroup Free Standards Group (FSG)
janina(a)freestandards.org http://a11y.org
Janina Sajka Phone: +1.202.494.7040
Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com
Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to
http://www.ScreenlessPhone.Com to learn more.
21 Jun
21 Jun
7:18 a.m.
Janina Sajka <janina(a)rednote.net> writes:
No UI I am afraid. I will control the hdsposc thing from within
SuperCollider with OSC messages directly.
--
CYa,
Mario
Since I
finally ordered my Multiface, I also started to write
a small program which I am going to need since hdspconf and hdspmixer
are both GUI only.
The idea:
hdsposc will offer the RME mixer and the metering functionality
via OSC.
Why do I write this mail? I'd like to know if someone else
could also make use of this tool. If so, I'd like to hear
your input what you'd want to exactly do with it. If no one responds,
I'll save coding time by ONLY implementing the Multiface (since thats
what I can test) and probably not polish it much, since
what I need is probably very basic.
I would use this. Thank you.
I also have nothing to add at this point in terms of feature requests.
At the moment I have a Multiface only.
Are you contemplating a ncurses type u-i? Emacs? CLI? 
3:30 p.m.
On Tue, Jun 21, 2005 at 11:19:52AM +0200, Mario Lang wrote:
No UI I am afraid. I will control the hdsposc thing
from within
SuperCollider with OSC messages directly.
Then I wonder why you need this at all. You can connect raw ins/outs
to SC, and do everything the mixer can do there ??
--
FA
22 Jun
22 Jun
5:40 a.m.
fons adriaensen <fons.adriaensen(a)skynet.be> writes:
On Tue, Jun 21, 2005 at 11:19:52AM +0200, Mario Lang
wrote:
No, I can't. The RME mixer is Zero-Latency, i.e, it routes
certain ports to others, without going through the OS. Granted, that can
be done with amixer as well, but I just found that out after
I started to hack hdsposc...
The peak metering I could hack in SC, yes, but why should I if my hardware
already does it? :-)
Perhaps I should put it in other words: My UI is going to be
a class in SC.
HDSP.peak(\analog, (1..8), {|peaks|peaks.dbamp.postln});
Or some such...
--
CYa,
Mario
No UI I am afraid. I will control the hdsposc
thing from within
SuperCollider with OSC messages directly.
Then I wonder why you need this at all. You can connect raw ins/outs
to SC, and do everything the mixer can do there ??
6 Jul
6 Jul
10:49 a.m.
Janina Sajka <janina(a)rednote.net> writes:
Janina, I finally put up a preliminary tarball of what I currently
have. It definitely needs some cleaning up, and there is no
readymade user interface yet, you would have to talk to it
using something cpaable of emitting OSC messages. A
very simple class for SuperCollider to do this is included.
For now, you'd need to read the hdsposc.c source file to figure
out how to use it, but hey :-).
http://delysid.org/hdsposc.tar.bz2
I'll keep you informed as soon as I find some time to clean
it up some more. Whats left for me to do is to make
channels symbolic names. Currently, you have to use the same cryptic
numbers as with amixer, i.e., in doublespeed mode, analog in #8
is actually 11! :-). Ideally, I'd like to handle this in the hdsposc
code and just accept messages like:
/route "AN8" "LO1" 0
for routing analog in #8 to line out left, with 0 dB attenuation.
The /route command takes attenuation already in dB, not
integers from 0 to 65535. I find dB lots easier to
work with :-)
Since I
finally ordered my Multiface, I also started to write
a small program which I am going to need since hdspconf and hdspmixer
are both GUI only.
The idea:
hdsposc will offer the RME mixer and the metering functionality
via OSC.
Why do I write this mail? I'd like to know if someone else
could also make use of this tool. If so, I'd like to hear
your input what you'd want to exactly do with it. If no one responds,
I'll save coding time by ONLY implementing the Multiface (since thats
what I can test) and probably not polish it much, since
what I need is probably very basic.
I would use this. Thank you.
I also have nothing to add at this point in terms of feature requests.
At the moment I have a Multiface only. Are you contemplating a ncurses type u-i? Emacs? CLI?
Do you have a layout idea how a Ncurses/CLI UI should look like?
How should we go about displaying 18*3 channels of metering info?
For me as a braille user, everything is acceptable, but I gather you probably
want to give some feedback regarding using it with speech...
--
CYa,
Mario
6870
days inactive
6891
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
5 participants
participants (5)
-
Arnold Krille -
fons adriaensen -
Janina Sajka -
Mario Lang -
thomas charbonnel