Menu
▾
▴
linuxsampler-devel
|
From: Rui N. C. <rn...@rn...> - 2004-06-21 19:01:21
|
Hi,
In my own trials to re-implement SET CHANNEL AUDIO_OUTPUT_TYPE command,
I've stumbled in a precise question which I hope the LS engine designer(s)
would answer:
How can I determine the driver type of an AudioOutputDevice class
instance? That is, whether it inherits from AudioOutputDeviceAlsa ("Alsa")
or AudioOutputDeviceJack ("Jack").
OTOH, that driver name is supposed to be included in the resultset of GET
AUDIO_OUTPUT_DEVICE INFO command, but isn't so, at least in the current
implementation.
I'd rather have someone giving some hints on how to get this, before I do
something really hackish ;)
My idea to recreate the LSCPSErver::SetAudioOutputType(String sDriver)
method goes almost like this:
{
// Check if there's one audio device already created
// of the intended type (sDriver)...
AudioOutputDevice *pDevice = NULL;
std::map<uint, AudioOutputDevice*> devices =
pSampler->GetAudioOutputDevices();
std::map<uint, AudioOutputDevice*>::iterator iter = devices.begin();
for (; iter != devices.end(); iter++) {
if (iter->second is of sDriver type) { // HOW?
pDevice = iter->second;
}
}
// If it doesn't exist, create a new one with default parameters...
if (pDevice == NULL)
pDevice = pSampler->CreateAudioOutputDevice(sDriver);
// Set it as the current channel device...
pSampler->SetAudioOutputDevice(pDevice);
}
Obviously, my question is summarized on how to write the pseudo-code on
the line with the HOW? comment.
Christian?
Vladimir?
Benno?
Anyone? :)
--
rncbc aka Rui Nuno Capela
rn...@rn...
|
|
From: Vladimir S. <ha...@so...> - 2004-06-22 00:49:23
|
Hi Rui,
Looks like you are trying to create an audio device at runtime but why
do you care if one of that type already exists or not? What about the
parameters? Two alsa devices for example can have completely different
parameters such as output cards, etc, etc. I'm not sure what the desired
effect would be . . . if we are trying to simulate single channel
shouldn't we just delete all audio ouputs before creating a new one? :)
Just kidding.
You could try playing with <typeinfo> but it will probably be easier to
just add a pure virtual into AudioOutputDevice base and implementations
for that into Alsa and Jack classes respectively and that will probably
be the easiest way to get that kind of info. Basically like we do with
versions and descriptions.
If this is purely for backward compatibilty you might as well just
always create a new audio device . . . since parameters are not going to
be correct anyways it will work just as good :)
I think backward compatibility is important once we actually
ship/release something. Once we have an installbase/userbase, etc. For
right now, we are developing, not using :) We already are at 11th
version of the spec . . . chances are we'll have to first implement
protocol FULLY, then we'll reallize some things are still missing or
suboptimal, etc, etc. THEN we'll fix and polish those things in both
spec and software and then some alpha/beta folks will hopefully give
this combination some testing and based on their feedback we'll correct
things again. Hopefully releasing the whole thing soon after that step.
In other words, we are not "code complete" yet, we are still in development.
So we are not there yet and i'm not too worried about the backwards
compatibility just yet :)
BTW, i've just checked in a SET command to map channels to audio output.
Still plenty of stuff to fix though. I'm hoping to get to input next and
then it might sort of start working again (a little bit :)
Regards,
Vladimir.
PS: Are you serious about backwards compatibility or are just just
kidding? I can't tell when you are kidding or not because you seem to
always be happy :)
Rui Nuno Capela wrote:
>Hi,
>
>In my own trials to re-implement SET CHANNEL AUDIO_OUTPUT_TYPE command,
>I've stumbled in a precise question which I hope the LS engine designer(s)
>would answer:
>
>How can I determine the driver type of an AudioOutputDevice class
>instance? That is, whether it inherits from AudioOutputDeviceAlsa ("Alsa")
>or AudioOutputDeviceJack ("Jack").
>
>OTOH, that driver name is supposed to be included in the resultset of GET
>AUDIO_OUTPUT_DEVICE INFO command, but isn't so, at least in the current
>implementation.
>
>I'd rather have someone giving some hints on how to get this, before I do
>something really hackish ;)
>
>My idea to recreate the LSCPSErver::SetAudioOutputType(String sDriver)
>method goes almost like this:
>{
> // Check if there's one audio device already created
> // of the intended type (sDriver)...
> AudioOutputDevice *pDevice = NULL;
> std::map<uint, AudioOutputDevice*> devices =
>pSampler->GetAudioOutputDevices();
> std::map<uint, AudioOutputDevice*>::iterator iter = devices.begin();
> for (; iter != devices.end(); iter++) {
> if (iter->second is of sDriver type) { // HOW?
> pDevice = iter->second;
> }
> }
>
> // If it doesn't exist, create a new one with default parameters...
> if (pDevice == NULL)
> pDevice = pSampler->CreateAudioOutputDevice(sDriver);
>
> // Set it as the current channel device...
> pSampler->SetAudioOutputDevice(pDevice);
>}
>
>Obviously, my question is summarized on how to write the pseudo-code on
>the line with the HOW? comment.
>
>Christian?
>Vladimir?
>Benno?
>Anyone? :)
>
>
|
|
From: Vladimir S. <ha...@so...> - 2004-06-22 01:03:41
|
Rui, Forgot to mention that LOAD_INSTRUMENT can now be tested (and appears to work OK with both background and foreground) on channels that have ENGINE loaded and AUDIO_OUTPUT mapped . . . Maybe i should just throw an exception in lscp server when instrument loading is attempted before audio output is mapped, since it is required at the instrument loading time. On the other hand, i never bothered to look why was it required . . . maybe i should do that first. For now just please do things in the following order: CREATE AUDIO_OUTPUT_DEVICE Alsa card='0,0' ADD CHANNEL ---- the above two can really be done in any order, assuming they both have returned OK[0]----- LOAD ENGINE gig 0 SET CHANNEL AUDIO_OUTPUT_DEVICE 0 0 LOAD INSTRUMENT 'file.gig' 0 0 or LOAD INSTRUMENT NON_MODAL 'file.gig' 0 0 Regards, Vladimir. |
|
From: Rui N. C. <rn...@rn...> - 2004-06-22 12:15:07
Attachments:
linuxsampler-0.2-cvs20040622b.patch.gz
|
Hi,
For your patching pleasure :) you may try and test the attached diff-patch
onto current CVS HEAD, which is my latest attempt on keeping backward
compability with older (pre-June13th) linuxsampler LSCP client interfaces.
The fine print goes like this:
* SET CHANNEL AUDIO_OUTPUT_TYPE <chan> <driver> command is back! :)
I know it's been deprecated, but I think it's too early to break
existing LSCP scripts or clients (e.g. qsampler), preventing them
to work properly with the new and future linuxsampler code. It
creates an audio output device instance of the given driver type
("Jack" or "Alsa") with default parameters if none exists,
otherwise it just picks the first available device and assign it
to the intended sampler channel.
It's basicaly equivalent to the follwing commands in succession:
CREATE AUDIO_OUTPUT_DEVICE <driver>
SET CHANNEL AUDIO_OUTPUT_DEVICE <chan> <devno>
* The AudioOutputDevice class get's a new pure virtual method,
Driver(), which is implemented on both of the existing inherited
classes, AudioOutputDeviceAlsa and AudioOutputDeviceJack, with
the sole purpose to return the driver type name as a String
("Alsa" and "Jack", respectively).
* The quoting on the filename argument for the LOAD INSTRUMENT
command has been made optional; you can have both ways, with
single quotes or none, keeping compability with older LSCP
specification.
* An additional sanity check is made on LOAD INSTRUMENT, whether
the sampler channel has an audio output device assigned, thus
preventing the server from crashing on instrument file load.
* The GET AUDIO_OUTPUT_DEVICE INFO now includes the missing
"driver" item, as predicted by the draft protocol document.
IMPORTANT: As the patch includes small changes on the lex/yacc sources,
you must issue 'make parser' under src/network, before the top level
'make'.
Please notice that these changes will make current linuxsampler CVS
virtally compatible and functional with "older" LSCP scripts and client
interfaces (e.g. qsampler/liblscp). I think it's worth the effort, now
that it's already done ;)
As before, I'm ready to commit this stuff, as soon as there's some
positive feedback. Dictators may speak now...
Take care.
--
rncbc aka Rui Nuno Capela
rn...@rn...
P.S. Vladimir, as you can see now, I was serious about this backward
compability issue, although it may seem that I'm always happy :) In fact,
I'm really happy to suggest these changes, and most certainly, will be
happier if you and everyone else agrees, just because I think, everybody
would be happier too.
Happy patching! :)
|
Thanks for helping keep SourceForge clean.
X