Discussion:
We're testing JackdMP-0.44, darkice-cvs, and Lame-cvs Altivec patches (for OSX-Tiger)
(too old to reply)
s***@hush.ai
2005-12-17 03:45:29 UTC
Permalink
Hi,

The regular jackd (from cvs) is still having a few buffering
problems with darkice (from cvs) running on OSX-Tiger 10.4.3, even
with my make-it-big patch on darkice.

We're testing Stephane's JackdMP-0.44 pkg now, and things are quite
a lot better. JackdMP can load its own jack_coreaudio.so driver,
whereas jackit-cvs has problems loading its own, but jackit-cvs can
(only) use its jack_portaudio.so driver which is probably where our
buffering problems reside. (All that is under OSX-Tiger.)
Building and running jackit-cvs under OSX-Panther works fine with
its own jack_coreaudio.so driver built there ... somewhere in all
this is a clue to our woes under Tiger. ;)

I've (re)compiled everything using Apple's XCode-2.2 gcc-4.0.1 etc.
and tweaks for a PPC-7450 (newer G4).

Also, I patched Lame cvs with those Altivec patches mentioned on
the lame-devel list. Even tho we have a G4, I put on all of the G5
patches, and gcc did not complain, and we've yet to crash either.
:)

If you'd like to give us a test:

We are listed and use a variety of netcast software. For now, to
find the station, please go to the following Yellow Pages and
search for ‘KOKF’:

(plain) Shoutcast - <http://yp.shoutcast.com/directory/?s=KOKF>
(plain) Icecast - <http://dir.xiph.org/index.php?search=KOKF>
(plain) RadioToolBox - <http://www.radiotoolbox.com/steamcast/>
(plain) Steamcast - <http://www.steamcast.com/?t=&g=&s=KOKF>
(p2p) Peercast -
<http://yp.peercast.org/?find=KOKF&Submit=Search>
(p2p) P2P-Radio - <http://p2p-radio.sourceforge.net/stations/>
(p2p) S2S-Radio - <http://s2s.sourceforge.net/stations/>


For now, we are using maximum 320K MP3 bitrate and can handle only
a few connections. I am hoping we (you-all and me) can use p2p
software to handle more connections. The idea is to eventually
have you become an “affiliate” that can take the high-quality
signal (the “backbone”) then have your relay locally “transcode” it
for your local listeners esp. those on dial-up lines needing lower
bitrates – all across the world. (More on this idea is posted on
the Peercast forum at
<http://www.peercast.org/forum/viewtopic.php?p=10654#10654>.)

p.s.

We relay a local Christian FM station that is way ahead of others,
very contemporary. We only netcast the dance/ trance/ house/ dnb/
breaks stuff on Friday nights and Saturday nights U.S. time (only,
no fear of RIAA this way, see <g>).

I am only an avid listener who can engineer the netcast, not a DJ
or anything like that, but the station does know we are doing this,
but I would like Christian youth (and young-at-heart) to know about
this, too. There is absolutely no preaching nor commercials during
these dance nights, so people can simply enjoy the music and know
they will not hear any other raunchy stuff either.

The station/church website is at <http://www.KOKF.com/>.

Some of the dance mixes are available as original high-quality MP3s
for download at <http://www.LiftedRadio.com/>. (I've got a
personal archive of more...)

A virtual prize if you know what KOKF stands for. <g>

Thank you for reading this and for your help.





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Stéphane Letz
2005-12-17 09:06:37 UTC
Permalink
Post by s***@hush.ai
Hi,
The regular jackd (from cvs) is still having a few buffering
problems with darkice (from cvs) running on OSX-Tiger 10.4.3, even
with my make-it-big patch on darkice.
We're testing Stephane's JackdMP-0.44 pkg now, and things are quite
a lot better. JackdMP can load its own jack_coreaudio.so driver,
whereas jackit-cvs has problems loading its own,
Can you explain precisely what happens? Did you try the jackosx package?
Post by s***@hush.ai
but jackit-cvs can
(only) use its jack_portaudio.so driver which is probably where our
buffering problems reside.
The port audio driver use an intermediate ring-buffer, in particular
to deal with interfaces (like USB one) that appears internally as 2
separated coreaudio devices.
On Tiger this sort or device should better be "assembled" in a unique
aggregate device that can then be used normally by the jack coreaudio
driver.
Post by s***@hush.ai
(All that is under OSX-Tiger.)
Building and running jackit-cvs under OSX-Panther works fine with
its own jack_coreaudio.so driver built there ... somewhere in all
this is a clue to our woes under Tiger. ;)
I've (re)compiled everything using Apple's XCode-2.2 gcc-4.0.1 etc.
and tweaks for a PPC-7450 (newer G4).
Stephane

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
s***@hush.ai
2005-12-17 11:14:04 UTC
Permalink
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
Hi,
The regular jackd (from cvs) is still having a few
buffering problems with darkice (from cvs) running
on OSX-Tiger 10.4.3, even with my make-it-big patch
on darkice.
We're testing Stephane's JackdMP-0.44 pkg now, and
things are quite a lot better. JackdMP can load
its own jack_coreaudio.so driver, whereas
jackit-cvs has problems loading its own,
Can you explain precisely what happens? Did you try
the jackosx package?
Just now, I discovered an apparent requirement with the
jack_coreaudio.so driver (only): the System Prefs Sound
Panel must be set to whichever Input and Output you
intend to use with jackit-cvs. The jack_portaudio.so
driver didn't complain about mismatched settings here.

I'm not sure if you got my e-mail back on Sept.29 about
how we were trying to use the M-Audio Delta Audiophile
2496 PCI card here. Many of us were complaining that
M-Audio needed to fix their own driver for Tiger. Just
in the past two weeks they /finally/ released 2.0.5 that
seems to have most bugs fixed. Here, we had to continue
using Panther until M-Audio was fixed, so just this week
I jumped back onto these projects.

Okay... the reason JackdMP is working: it runs under the
current user, and that user's Sound Panel Prefs are set
correctly to match what we told JackdMP to use.

Why did jackit-cvs not work? We do "login -p root" in
order to get realtime priviledges. Guess who did not
have correct Sound Panel settings? Yep, the root user
never was set-up there. ;)

Just now we made sure these settings are correct for
root as well. Now jackit-cvs can load the
jack_coreaudio.so driver and continue using it.

Of course, doing this under root also requires darkice
to run as root. Nothing else needs to be root because
communications after that point is done thru TCP/IP to
the sc_serv or icecast or whatever.

Before realizing root's Sound Panel settings were not
correct, I did try running JackdMP as root, and indeed
it failed.

So there is some kind of hidden requirement for the time
being that Sound Panel settings must precisely match
what you intend to make jackit use. ;)

As added measure, since many makes-&-models cards can
have multiple inputs and outputs, use the Audio/MIDI app
to restrict those choices. In my case, I only want
standard 2-channel input & output, so Audio/MIDI app was
set-up that way. This helps jackit (and darkice) to
automatically connect to the first (two) ports, and you
do not need a jack connection tool.

Since everything goes thru CoreAudio, these settings are
saved system-wide, so any such app will see these same
parms.

I don't know why jack_portaudio.so did not complain with
mismatched settings. But I won't worry now. ;)

Under Panther, since we have used it for such a long
time (and then some!), I am sure the Sound Panel
settings were always correctly matching. So I /think/
this will explain everything.
Post by Stéphane Letz
Post by s***@hush.ai
but jackit-cvs can (only) use its jack_portaudio.so
driver which is probably where our buffering
problems reside.
The port audio driver use an intermediate
ring-buffer, in particular to deal with interfaces
(like USB one) that appears internally as 2
separated coreaudio devices.
On Tiger this sort or device should better be
"assembled" in a unique aggregate device that can
then be used normally by the jack coreaudio driver.
I wonder if fully setting up such a (USB) device will
benefit by going thru the Audio/MIDI app to make sure
the needed ports are the ones available? And of course
the need to get the Sound Panel settings to match, too.
Post by Stéphane Letz
Post by s***@hush.ai
[...]
Stephane
Okay I will run jackit-cvs for Saturday night's netcast.

And now for something different...

I think we are seeing another bug in darkice, similar to
what was reported by others on the darkice maillist.
When the "bytes sent to encoders" reaches 2GB, darkice
begins to falter and soon exits itself. Here is what I
saw tonight -twice- after about 4 hours each, precisely,
AFAICR:

---darkice-console-log---
[...no msgs for quite a long time, then:...]
17-Dec-2005 03:16:13 failed to write to ring ruffer
17-Dec-2005 03:17:47 Warning: Read a different number of samples
for left and right channels
17-Dec-2005 03:17:48 MultiThreadedConnector :: transfer, can't read
17-Dec-2005 03:17:48 2043506684 bytes transfered to the encoders
17-Dec-2005 03:17:48 encoding ends
---darkice-exits-itself-here---

We reach this limit quickly since we use 320K MP3
bitrate and 48kHz sample rate.

I don't know if patching darkice/src/JackDspSource.cpp
any bigger will help here. This is the same patch I
mentioned on these lists just this week:

---cut-here---
--- src/JackDspSource.cpp_orig 2005-12-02 23:07:09 -0600
+++ src/JackDspSource.cpp 2005-12-02 23:21:31 -0600
@@ -234,7 +234,7 @@


// Create a ring buffer for each channel
- rb_size = 2
+ rb_size = 32
* jack_get_sample_rate(client)
* sizeof (jack_default_audio_sample_t);
for (c=0; c<getChannel(); c++) {
---cut-here---

I believe I saw something on oddcast.org's forums in
that someone had rewritten this area of code to make it
act better like a "ring" and be recoverable rather than
flat-out quitting. I'll see if I can dig that up
again...

If anyone has further ideas, I'll try them out.
Thank you for helping.





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Stéphane Letz
2005-12-17 12:53:45 UTC
Permalink
Post by s***@hush.ai
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
Hi,
The regular jackd (from cvs) is still having a few
buffering problems with darkice (from cvs) running
on OSX-Tiger 10.4.3, even with my make-it-big patch
on darkice.
We're testing Stephane's JackdMP-0.44 pkg now, and
things are quite a lot better. JackdMP can load
its own jack_coreaudio.so driver, whereas
jackit-cvs has problems loading its own,
Can you explain precisely what happens? Did you try
the jackosx package?
Just now, I discovered an apparent requirement with the
jack_coreaudio.so driver (only): the System Prefs Sound
Panel must be set to whichever Input and Output you
intend to use with jackit-cvs. The jack_portaudio.so
driver didn't complain about mismatched settings here.
I'm not sure if you got my e-mail back on Sept.29 about
how we were trying to use the M-Audio Delta Audiophile
2496 PCI card here. Many of us were complaining that
M-Audio needed to fix their own driver for Tiger. Just
in the past two weeks they /finally/ released 2.0.5 that
seems to have most bugs fixed. Here, we had to continue
using Panther until M-Audio was fixed, so just this week
I jumped back onto these projects.
Okay... the reason JackdMP is working: it runs under the
current user, and that user's Sound Panel Prefs are set
correctly to match what we told JackdMP to use.
Why did jackit-cvs not work? We do "login -p root" in
order to get realtime priviledges.
Hum... what kind of realtime priviledges do you need that require
root? real-time threading can be done on normal account on OSX....
Post by s***@hush.ai
Guess who did not
have correct Sound Panel settings? Yep, the root user
never was set-up there. ;)
I was not aware of any issue related to the Sound Pref setting.
The jack coreaudio driver is supposed to use the audio device set
using the -n parameter.
If no -n is used then the system default device will be used instead.

Default device is set using Audio/MIDI setup

Stephane




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
s***@hush.ai
2005-12-17 23:02:05 UTC
Permalink
Post by Stéphane Letz
Post by s***@hush.ai
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
Hi,
The regular jackd (from cvs) is still having a few
buffering problems with darkice (from cvs) running
on OSX-Tiger 10.4.3, even with my make-it-big patch
on darkice.
We're testing Stephane's JackdMP-0.44 pkg now, and
things are quite a lot better. JackdMP can load
its own jack_coreaudio.so driver, whereas
jackit-cvs has problems loading its own,
Can you explain precisely what happens? Did you try
the jackosx package?
Just now, I discovered an apparent requirement with the
jack_coreaudio.so driver (only): the System Prefs Sound
Panel must be set to whichever Input and Output you
intend to use with jackit-cvs. The jack_portaudio.so
driver didn't complain about mismatched settings here.
I'm not sure if you got my e-mail back on Sept.29 about
how we were trying to use the M-Audio Delta Audiophile
2496 PCI card here. Many of us were complaining that
M-Audio needed to fix their own driver for Tiger. Just
in the past two weeks they /finally/ released 2.0.5 that
seems to have most bugs fixed. Here, we had to continue
using Panther until M-Audio was fixed, so just this week
I jumped back onto these projects.
Okay... the reason JackdMP is working: it runs under the
current user, and that user's Sound Panel Prefs are set
correctly to match what we told JackdMP to use.
Why did jackit-cvs not work? We do "login -p root" in
order to get realtime priviledges.
Hum... what kind of realtime priviledges do you need
that require root? real-time threading can be done
on normal account on OSX....
It says so in the various jackd docs, man-page, etc.
Plus maybe the 'actual' root requirement was with darkice,
I'll need to dig-up that info...
(darkice's configure script btw does not detect POSIX
on Tiger for some reason, so I use "renice -20"...)

I've discovered yet another bug, too. When running
jackd on root, we cannot Ctrl+C out of it, ^C shows but
ignored totally. ISTR another user mentioned this some
time back on the jackit list, on another platform.
Doing a kill from another shell/window will end it.

I know I know: File bug reports. ;)
Post by Stéphane Letz
Post by s***@hush.ai
Guess who did not have correct Sound Panel
settings? Yep, the root user never was set-up
there. ;)
I was not aware of any issue related to the Sound
Pref setting. The jack coreaudio driver is supposed
to use the audio device set using the -n parameter.
If no -n is used then the system default device
will be used instead.
Respectfully, has jackit been tested on a Mac with
multiple sound devices from different vendors?

I'm certain this default device setting was mentioned
somewhere before, I just can't remember now, but since I
fell into the same problem, I seem to remember this was
mentioned before. At least now I hope it'll get
recorded & remembered now. ;)

btw This is how I start up jackd:

#---cut-here---
/usr/local/bin/jackd \
--realtime \
--timeout 0 \
-d coreaudio \
--channelin 2 \
--channelout 2 \
--rate 48000 \
--period 1024 \
--playback 0 \
--capture 1 \
--input-latency 5500 \
--name "Delta Audiophile 2496"
#---cut-here---

I make sure M-Audio's control panel has the same rate
settings etc., too.

M-Audio won't use a period higher than 1024. This turns
into an offset value of 4096 which precisely matches
their hardware buffersize (the author for LibMikMod
project's coreaudio driver helped me figure that out).

I don't care about high latency, this is just a netcast
of an OTA radio station. I do need big buffers (and big
TCP/IP sendspaces) since apparently it helps with
buffering & skipping issues etc.
Post by Stéphane Letz
Default device is set using Audio/MIDI setup
It just so happens the default device is shown correctly
on the System Prefs Sound Panel, too, when it is changed
either way. Perhaps M-Audio's driver does this
under-the-covers, and maybe another vendor will not do
this.
Post by Stéphane Letz
Stephane
Thanks for discussing this. I'll give this a test for
tonight's netcast (starting in about 2 hours from this
post).





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Stéphane Letz
2005-12-18 08:48:17 UTC
Permalink
Post by s***@hush.ai
It says so in the various jackd docs, man-page, etc.
Plus maybe the 'actual' root requirement was with darkice,
I'll need to dig-up that info...
Yes its the case on Linux, but not on OSX...
Post by s***@hush.ai
(darkice's configure script btw does not detect POSIX
on Tiger for some reason, so I use "renice -20"...)
#---cut-here---
/usr/local/bin/jackd \
--realtime \
--timeout 0 \
-d coreaudio \
--channelin 2 \
--channelout 2 \
--rate 48000 \
--period 1024 \
--playback 0 \
--capture 1 \
--input-latency 5500 \
--name "Delta Audiophile 2496"
#---cut-here---
There is an issue here : the --name parameter is incorrect. For
various reason, the name you have to give in --name is not the name
you would see in Audio/Midi setup (that has localization issue) but
an *internal* name of the driver that is a bit more difficult to
figure out. So you can either:

- use JackPilot from the jackosx package to launch the "Delta
Audiophile 2496", then look at the real command that is done (doing
ps -ax) and take the appropriate name or

- use the HalLab (a tool available in the Developer package that
allows to scan all audio device on the machine) You can see the audio
device internal name with it.

If the -name can not be found (which is you case...) the the default
driver as choosen in Audio/Midi setup will be loaded.

Stephane .




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
s***@hush.ai
2005-12-19 09:24:33 UTC
Permalink
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
It says so in the various jackd docs, man-page,
etc. Plus maybe the 'actual' root requirement was
with darkice, I'll need to dig-up that info...
Yes its the case on Linux, but not on OSX...
Perhaps we OSX users can patch the docs to say that. ;)
Post by Stéphane Letz
Post by s***@hush.ai
[...]
#---cut-here---
/usr/local/bin/jackd \
--realtime \
--timeout 0 \
-d coreaudio \
--channelin 2 \
--channelout 2 \
--rate 48000 \
--period 1024 \
--playback 0 \
--capture 1 \
--input-latency 5500 \
--name "Delta Audiophile 2496"
#---cut-here---
There is an issue here : the --name parameter is
incorrect. For various reason, the name you have to
give in --name is not the name you would see in
Audio/Midi setup (that has localization issue) but
an *internal* name of the driver that is a bit more
- use JackPilot from the jackosx package to launch
the "Delta Audiophile 2496", then look at the real
command that is done (doing ps -ax) and take the
appropriate name or
I have a side-problem with these other jack* projects.
I have sync'd my copy with their cvs. I also pulled the
cvs of the full Panda src. All of them need
Java.framework, none of them provide the src for that, I
see no docs on how to get the src for that. So I cannot
build projects that are incomplete like that.

OTOH your projects build your own frameworks e.g.
Jack[d]mp.framework, but not the plain Jack.framework --
also IIRC your JackPilotMP app is missing its src, too,
so I cannot build it (at least in your 0.44 pkg).
(Being able to build the binary pkgs is my requirement
so I can show OSX in its best open-source light.)
Post by Stéphane Letz
- use the HalLab (a tool available in the Developer
package that allows to scan all audio device on the
machine) You can see the audio device internal name
with it.
I've finally dug thru the /Developer tree to find it.

I know these projects are in infancy, so such
"experiments" on other platforms are going to need a lot
more work such as messing with HALLab. So take my words
here only as a goal to reach for a "milestone release"
that will be ready for regular non-technical end-users,
please.

The thing to do is to write jackd in the same way these
other apps (including yours in the GUI, Audio/MIDI
Setup, HALLab, etc. etc. etc.) handle audio device
selection: produce a user-friendly name rather than
force the (non-technical end-)user to dig and dig and
dig to discover the ugly internal name.

Otherwise is installing the Developer Kit going to be a
requirement for end-users that do not have it installed
-- but need to discover their ugly internal name for
their third-party hardware, unless we make jackd do it
itself in a more user-friendly way, again as most other
apps do (including yours)?
Post by Stéphane Letz
If the -name can not be found (which is you case...)
the the default driver as choosen in Audio/Midi
setup will be loaded.
No jackd did not choose the default driver, it simply
quit when the settings did not match. And only when it
is told to use the jack_coreaudio.so driver.

OTOH the jack_portaudio driver glady took the parms
IIRC.

It could be that jackd ended abruptly because of this
scenario in my case: jack_coreaudio could not set some
parms, esp. 48000 sample rate, on the "Built-in Audio"
chip, which AFAIK no Sawtooth model can do (it's
strictly 44100, 16-bit, nothing else).

But jackd --verbose apparently did not produce any text
that would describe what it is actually doing. That
makes it terribly difficult to find out what is wrong on
(non-technical) end-user systems.

Does the jack_coreaudio src receive the --verbose flag
at all so it can print out such info when things go
wrong at that level?

Do you see what I'm trying to say now?

As for jack_portaudio, it seems it can handle
sample-rate conversions so it does not complain about
hardware mismatches like this. IIRC the portaudio v18_1
src has as a project requirement for libsamplerate to do
just that, see. So perhaps that is why we didn't see
the same problem with it as we saw with jack_coreaudio
in our environment here.

I'm using latest cvs that I can find for all projects
mentioned here. (But remember my complaint that I
cannot build some of them since I cannot locate where
original Jack.framework src is built -- and this should
be based on cvs of jackit, too, btw.)

fwiw I'd much rather have command-line jackit working,
it can be made hidden better, and uses only *ix-type
resources, so we are getting closer to being on par
with other platforms that way. I really don't want to
need GUIs to do any of this. ;)
Post by Stéphane Letz
Stephane .
Thank you for discussing this. I hope I don't sound too
strong, I had a medical problem to deal with at the
emergency room since my last post and not feeling so
good right now.





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Stéphane Letz
2005-12-19 09:44:30 UTC
Permalink
Post by s***@hush.ai
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
It says so in the various jackd docs, man-page,
etc. Plus maybe the 'actual' root requirement was
with darkice, I'll need to dig-up that info...
Yes its the case on Linux, but not on OSX...
Perhaps we OSX users can patch the docs to say that. ;)
It's documented here :

http://www.jackaudio.org/index.php?
option=com_content&task=view&id=12&Itemid=26#a56
Post by s***@hush.ai
Post by Stéphane Letz
Post by s***@hush.ai
[...]
#---cut-here---
/usr/local/bin/jackd \
--realtime \
--timeout 0 \
-d coreaudio \
--channelin 2 \
--channelout 2 \
--rate 48000 \
--period 1024 \
--playback 0 \
--capture 1 \
--input-latency 5500 \
--name "Delta Audiophile 2496"
#---cut-here---
There is an issue here : the --name parameter is
incorrect. For various reason, the name you have to
give in --name is not the name you would see in
Audio/Midi setup (that has localization issue) but
an *internal* name of the driver that is a bit more
- use JackPilot from the jackosx package to launch
the "Delta Audiophile 2496", then look at the real
command that is done (doing ps -ax) and take the
appropriate name or
I have a side-problem with these other jack* projects.
I have sync'd my copy with their cvs. I also pulled the
cvs of the full Panda src. All of them need
Java.framework, none of them provide the src for that, I
see no docs on how to get the src for that. So I cannot
build projects that are incomplete like that.
OTOH your projects build your own frameworks e.g.
Jack[d]mp.framework, but not the plain Jack.framework --
also IIRC your JackPilotMP app is missing its src, too,
so I cannot build it (at least in your 0.44 pkg).
(Being able to build the binary pkgs is my requirement
so I can show OSX in its best open-source light.)
Post by Stéphane Letz
- use the HalLab (a tool available in the Developer
package that allows to scan all audio device on the
machine) You can see the audio device internal name
with it.
I've finally dug thru the /Developer tree to find it.
I know these projects are in infancy, so such
"experiments" on other platforms are going to need a lot
more work such as messing with HALLab. So take my words
here only as a goal to reach for a "milestone release"
that will be ready for regular non-technical end-users,
please.
The thing to do is to write jackd in the same way these
other apps (including yours in the GUI, Audio/MIDI
Setup, HALLab, etc. etc. etc.) handle audio device
selection: produce a user-friendly name rather than
force the (non-technical end-)user to dig and dig and
dig to discover the ugly internal name.
Otherwise is installing the Developer Kit going to be a
requirement for end-users that do not have it installed
-- but need to discover their ugly internal name for
their third-party hardware, unless we make jackd do it
itself in a more user-friendly way, again as most other
apps do (including yours)?
This internal name is needed only if you start jackd[mp] in a
terminal. Regular users would use a GUI like JackPilot of QjackClt
that show the user friendly name to the user.
Post by s***@hush.ai
Post by Stéphane Letz
If the -name can not be found (which is you case...)
the the default driver as choosen in Audio/Midi
setup will be loaded.
No jackd did not choose the default driver, it simply
quit when the settings did not match. And only when it
is told to use the jack_coreaudio.so driver.
OTOH the jack_portaudio driver glady took the parms
IIRC.
It could be that jackd ended abruptly because of this
scenario in my case: jack_coreaudio could not set some
parms, esp. 48000 sample rate, on the "Built-in Audio"
chip, which AFAIK no Sawtooth model can do (it's
strictly 44100, 16-bit, nothing else).
But jackd --verbose apparently did not produce any text
that would describe what it is actually doing. That
makes it terribly difficult to find out what is wrong on
(non-technical) end-user systems.
Does the jack_coreaudio src receive the --verbose flag
at all so it can print out such info when things go
wrong at that level?
Do you see what I'm trying to say now?
I know that things are not perfect... but you are doing things that
normal users would not do ... (;
Normal users would use JackPilot that display the possible parameter
the underlying audio device can handle : sample rate, names, input/
output numbers.

But things can probably be improved: patches are welcomed !
Post by s***@hush.ai
As for jack_portaudio, it seems it can handle
sample-rate conversions so it does not complain about
hardware mismatches like this. IIRC the portaudio v18_1
src has as a project requirement for libsamplerate to do
just that, see. So perhaps that is why we didn't see
the same problem with it as we saw with jack_coreaudio
in our environment here.
Probably: but software sample rate is something not done anymore in
the coreaudio driver. The driver reflects what the hardware can do.
Post by s***@hush.ai
I'm using latest cvs that I can find for all projects
mentioned here. (But remember my complaint that I
cannot build some of them since I cannot locate where
original Jack.framework src is built -- and this should
be based on cvs of jackit, too, btw.)
Its compiled from the config/os/macosx/jack.xcode project.
Post by s***@hush.ai
fwiw I'd much rather have command-line jackit working,
it can be made hidden better, and uses only *ix-type
resources, so we are getting closer to being on par
with other platforms that way. I really don't want to
need GUIs to do any of this. ;)
My first priority was to have a "user friendly" JackOSX package, and
i know using jack with command-line is a bit difficult on OSX.
Post by s***@hush.ai
Post by Stéphane Letz
Stephane .
Thank you for discussing this. I hope I don't sound too
strong, I had a medical problem to deal with at the
emergency room since my last post and not feeling so
good right now.
Stephane



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
s***@hush.ai
2005-12-19 11:17:53 UTC
Permalink
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
It says so in the various jackd docs, man-page,
etc. Plus maybe the 'actual' root requirement was
with darkice, I'll need to dig-up that info...
Yes its the case on Linux, but not on OSX...
Perhaps we OSX users can patch the docs to say
that. ;)
http://www.jackaudio.org/index.php?option=com_content&task=view&id=1
2&Itemid=26#a56

I only saw the BSD blurb there. The OSX blurb is right
above it at the #a55 tag. ;)

Apparenly my point is missed, tho: this tidbit needs to
be inside the Open Source docs, i.e. in the dist itself,
for that is what I was reading when setting things up to
get realtime privs. ;)

I know I know: submit patches etc. ;)
Post by Stéphane Letz
Post by s***@hush.ai
[...]
Otherwise is installing the Developer Kit going to
be a requirement for end-users that do not have it
installed -- but need to discover their ugly
internal name for their third-party hardware,
unless we make jackd do it itself in a more
user-friendly way, again as most other apps do
(including yours)?
This internal name is needed only if you start
jackd[mp] in a terminal. Regular users would use a
GUI like JackPilot of QjackClt that show the user
friendly name to the user.
Perhaps what I mean for jack_coreaudio -- and only
jack_coreaudio -- is something like what HALLab shows: a
Model UID that at least suggests the advertised
manufacturer's name of the card -- in my case this is:

"com_midiman_driver_Delta_AudioDevice:M-Audio Delta Audiophile 2496"

(sorry, the HALLab app will not let us copy-&-paste
this... adding to the frustration of "user
friendliness"... grr...)

The other item shown is a plain UID that is not a
user-friendly name:

"com_midiman_driver_Delta_AudioEngine:Delta_0x00000002:D6341412:0"

Now why does jack_coreaudio (apparently) treat "Built-in
Audio" differently? Or does it? In my case the plain
UID that HALLab shows for the on-board chip is this:

"AppleDBDMMAudioDMAEngine:0"

The Model UID for this:

"AppleScreamerAudio:DeviceName"

Even HALLab's selection buttons show a user-friendly
name together with a Device Number, then "Get Info" if
you need more details.

I surmise the very simple user-friendly name shown on
the buttons even for my Delta card is being obtained by
HALLab by interrogating the M-Audio driver itself. Then
HALLab adds a (Device ID#) string to that name, and
shows it on the selection button list.

Same thing for "Built-in Audio" on those buttons.

My main point in all this: I'm saying the translation of
a user-friendly name to the ugly internal name should be
done inside jack_coreaudio AS A STANDARD PROJECT-LEVEL
METHODICAL WAY or API rather than the multitude of GUIs
out there being developed. Base it on how HALLab is
doing it, the src code is there, we just need to cram it
into jack_coreaudio somehow. ;)

(I hope this idea is coming across right, I'm still not
well...)

So, technically jack_coreaudio presently wants everyone
to look up the plain UID to use as the --name parm no
matter what (on-board, third-party, etc.), or leave off
--name to use the Sound Panel Prefs default device.
Which method is easier? ;) I'd like to work on
instilling the user-friendly code inside jack_coreaudio
itself.
Post by Stéphane Letz
Post by s***@hush.ai
Post by Stéphane Letz
If the -name can not be found (which is you case...)
the the default driver as choosen in Audio/Midi
setup will be loaded.
No jackd did not choose the default driver, it simply
quit when the settings did not match. And only when it
is told to use the jack_coreaudio.so driver.
OTOH the jack_portaudio driver glady took the parms
IIRC.
It could be that jackd ended abruptly because of this
scenario in my case: jack_coreaudio could not set some
parms, esp. 48000 sample rate, on the "Built-in Audio"
chip, which AFAIK no Sawtooth model can do (it's
strictly 44100, 16-bit, nothing else).
But jackd --verbose apparently did not produce any text
that would describe what it is actually doing. That
makes it terribly difficult to find out what is wrong on
(non-technical) end-user systems.
Does the jack_coreaudio src receive the --verbose flag
at all so it can print out such info when things go
wrong at that level?
Do you see what I'm trying to say now?
I know that things are not perfect... but you are
doing things that normal users would not do ... (;
Yes I am doing things normal *ix users do: use
command-line apps. See, it's just a frame of mind. ;)

And M-Audio is quite a popular company in these regards.
Post by Stéphane Letz
Normal users would use JackPilot that display the
possible parameter the underlying audio device can
handle : sample rate, names, input/ output numbers.
See above. ;)
Post by Stéphane Letz
But things can probably be improved: patches are
welcomed !
I know I know: write the code and it'll be there. ;)

I will likely be wanting to work on jack_coreaudio to
instill a project-level method of determining a
user-friendly approach to the ugly internal names.
This I feel is where it belongs, not in the various
GUIs being developed out there. And HALLab can show
us how -- btw thank you for pointing me to it, very
much.
Post by Stéphane Letz
Post by s***@hush.ai
As for jack_portaudio, it seems it can handle
sample-rate conversions so it does not complain
about hardware mismatches like this. IIRC the
portaudio v18_1 src has as a project requirement
for libsamplerate to do just that, see. So perhaps
that is why we didn't see the same problem with it
as we saw with jack_coreaudio in our environment
here.
Probably: but software sample rate is something not
done anymore in the coreaudio driver. The driver
reflects what the hardware can do.
Yes I see that, and it is good that way. It drops a lot
of stuff we used to need to be worried about. Now we
can use the open-source apps in the way they were
intended, such as portaudio automatically determining if
it needs sample-rate conversion, etc. etc. etc.
Post by Stéphane Letz
Post by s***@hush.ai
I'm using latest cvs that I can find for all
projects mentioned here. (But remember my
complaint that I cannot build some of them since I
cannot locate where original Jack.framework src is
built -- and this should be based on cvs of jackit,
too, btw.)
Its compiled from the config/os/macosx/jack.xcode
project.
Oh wow if it was a snake I'd be dead now. I just looked
under my jackit-cvs dir. I feel totally embarrassed
now. Now you see how the medical problem got me
completely lost -- it was "right there under my nose".
Thank you for pointing it out, I will go build it asap.
Post by Stéphane Letz
Post by s***@hush.ai
fwiw I'd much rather have command-line jackit
working, it can be made hidden better, and uses
only *ix-type resources, so we are getting closer
to being on par with other platforms that way. I
really don't want to need GUIs to do any of this.
;)
My first priority was to have a "user friendly"
JackOSX package, and i know using jack with
command-line is a bit difficult on OSX.
Well, see I come from the days of *ix 20+ years ago. If
the CLI was designed to be more user-friendly to begin
with, the GUIs can just follow suit, and they'd all act
and expect the same. Most GUIs are simple wrappers for
CLIs. So that's why I'd be wanting to steer my efforts
to make jack_coreaudio do what it should.
Post by Stéphane Letz
Post by s***@hush.ai
[...]
Stephane
Thank you again, this has been very enlightening.





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Stéphane Letz
2005-12-19 12:00:24 UTC
Permalink
Post by s***@hush.ai
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
It says so in the various jackd docs, man-page,
etc. Plus maybe the 'actual' root requirement was
with darkice, I'll need to dig-up that info...
Yes its the case on Linux, but not on OSX...
Perhaps we OSX users can patch the docs to say
that. ;)
http://www.jackaudio.org/index.php?option=com_content&task=view&id=1
2&Itemid=26#a56
I only saw the BSD blurb there. The OSX blurb is right
above it at the #a55 tag. ;)
Apparenly my point is missed, tho: this tidbit needs to
be inside the Open Source docs, i.e. in the dist itself,
for that is what I was reading when setting things up to
get realtime privs. ;)
I know I know: submit patches etc. ;)
Post by Stéphane Letz
Post by s***@hush.ai
[...]
Otherwise is installing the Developer Kit going to
be a requirement for end-users that do not have it
installed -- but need to discover their ugly
internal name for their third-party hardware,
unless we make jackd do it itself in a more
user-friendly way, again as most other apps do
(including yours)?
This internal name is needed only if you start
jackd[mp] in a terminal. Regular users would use a
GUI like JackPilot of QjackClt that show the user
friendly name to the user.
Perhaps what I mean for jack_coreaudio -- and only
jack_coreaudio -- is something like what HALLab shows: a
Model UID that at least suggests the advertised
"com_midiman_driver_Delta_AudioDevice:M-Audio Delta Audiophile 2496"
(sorry, the HALLab app will not let us copy-&-paste
this... adding to the frustration of "user
friendliness"... grr...)
The other item shown is a plain UID that is not a
"com_midiman_driver_Delta_AudioEngine:Delta_0x00000002:D6341412:0"
Now why does jack_coreaudio (apparently) treat "Built-in
Audio" differently? Or does it? In my case the plain
"AppleDBDMMAudioDMAEngine:0"
"AppleScreamerAudio:DeviceName"
Even HALLab's selection buttons show a user-friendly
name together with a Device Number, then "Get Info" if
you need more details.
I surmise the very simple user-friendly name shown on
the buttons even for my Delta card is being obtained by
HALLab by interrogating the M-Audio driver itself. Then
HALLab adds a (Device ID#) string to that name, and
shows it on the selection button list.
Same thing for "Built-in Audio" on those buttons.
My main point in all this: I'm saying the translation of
a user-friendly name to the ugly internal name should be
done inside jack_coreaudio AS A STANDARD PROJECT-LEVEL
METHODICAL WAY or API rather than the multitude of GUIs
out there being developed. Base it on how HALLab is
doing it, the src code is there, we just need to cram it
into jack_coreaudio somehow. ;)
(I hope this idea is coming across right, I'm still not
well...)
So, technically jack_coreaudio presently wants everyone
to look up the plain UID to use as the --name parm no
matter what (on-board, third-party, etc.), or leave off
--name to use the Sound Panel Prefs default device.
Which method is easier? ;) I'd like to work on
instilling the user-friendly code inside jack_coreaudio
itself.
The main reason to switch form the "user friendly" name to the
"ugly" internal one was a localization issue. On french system for
instance "Built-in Audio"
appears as "Audio intégré when you use the
kAudioDevicePropertyDeviceName to get the driver name.

The localized version only appears is the process that use the
kAudioDevicePropertyDeviceName is itself localized, thus the
JackPilot would see "Audio intégré" when the jack coreaudio_driver
would like to see the non-localized one "Built-in Audio". I asked
last year on the coreaudio-mailing list how to *always* retrieve the
non-localized version but it appeared complex to handle, at least
more complex to switch to the "ugly" internal name that remains the
same everywhere.

In any case there is a translation needed at some point: a french
user would use Audio/Midi setup to look at the driver name (or system
preferences /Sound), see "Audio intégré", use jack -d coreaudio -n
"Audio intégré"... and it would fail...

There is no way for the french user to retrieve to non-localized
version but to use HALLab that (right now) display the non-localized
version...this is tricky also.

Now the coreaudio_driver use the plain UID (not the model UID)

So the "solution" I would see is to improve the --help stuff of the
coreaudio driver, to that all possible internal are displayed
(possibly associated with the user friendly non-localized version)
and document the issue to the user.

What do you think?

Stephane




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
s***@hush.ai
2005-12-20 08:07:20 UTC
Permalink
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
[...]
So, technically jack_coreaudio presently wants everyone
to look up the plain UID to use as the --name parm no
matter what (on-board, third-party, etc.), or leave off
--name to use the Sound Panel Prefs default device.
Which method is easier? ;) I'd like to work on
instilling the user-friendly code inside jack_coreaudio
itself.
The main reason to switch form the "user friendly"
name to the "ugly" internal one was a localization
issue. On french system for instance "Built-in
Audio" appears as "Audio int&#65533;gr&#65533; when you use the
kAudioDevicePropertyDeviceName to get the driver
name.
The localized version only appears is the process
that use the kAudioDevicePropertyDeviceName is
itself localized, thus the JackPilot would see
"Audio int&#65533;gr&#65533;" when the jack coreaudio_driver would
like to see the non-localized one "Built-in Audio".
I asked last year on the coreaudio-mailing list how
to *always* retrieve the non-localized version but
it appeared complex to handle, at least more complex
to switch to the "ugly" internal name that remains
the same everywhere.
In any case there is a translation needed at some
point: a french user would use Audio/Midi setup to
look at the driver name (or system preferences
/Sound), see "Audio int&#65533;gr&#65533;", use jack -d coreaudio
-n "Audio int&#65533;gr&#65533;"... and it would fail...
There is no way for the french user to retrieve to
non-localized version but to use HALLab that (right
now) display the non- localized version...this is
tricky also.
Now the coreaudio_driver use the plain UID (not the
model UID)
So the "solution" I would see is to improve the
--help stuff of the coreaudio driver, to that all
possible internal are displayed (possibly associated
with the user friendly non-localized version) and
document the issue to the user.
What do you think?
Stephane
Yes that sounds excellent (I saw your later post on
this, too).

I just had an idea, wonder if the following might help
for a long-range and more permanent plan:

I've watched the development of MPlayer for a long time
(over a year). This is the 'main' project, not the OSX
branch of it, but the latter does affect the main code.

By using a couple compile-time switches in its configure
script, the cmd-line mplayer can act as if it knows
about a bundle, but itself is a plain cmd-line app
(flat). Even if installed under /usr/local/bin i.e. not
inside the MPlayerOSX bundle, invoking mplayer will
cause Dock to show a generic grey icon (Unix file) as if
it was an OSX'ized app. But by putting this flat binary
inside a bundle, it should auto-magically respond to
actions such as Drag-&-Drop and be able to receive
..app-style arguments etc. plus (I think) to know about
Resources that translate messages (I think, can't test
it here ;) ).

Further, in order to build MPlayerOSX, it needs to have
the binaries made from the main MPlayer project. This
way we don't need to have multiple src trees of the main
code. (This is something I've never been sure about,
e.g. upon what version of jackit is jackosx and your
JackdMP based -- is it on 0.100.0 or 0.100.7 or even cvs
etc.)

So maybe jackd could follow suit, and jack_coreaudio
inherit these qualities from its caller -- i.e.
hypothetically, when jackd is merged into the jackosx or
_your_ GUI bundle, it should auto-magically become an
..app-style program and be able to handle localisation by
itself. But we have only one main code-base which is in
the jackit project. If after jackd becomes
knowledgeable of bundles and language resources etc., it
could also support writing & reading Preferences in the
standard OSX way, too -- then your GUIs would truly
become standardised. Your --help feature could actually
set those Prefs on behalf of the end-user.


Now to switch to another issue. I checked the files
installed by M-Audio. Nothing is localised, I see no
Resource subdirs anywhere. Instead, I think M-Audio
distributes different language drivers depending on in
which country their web-site is located. That means the
strings are hard-coded within the binary, and not in
Resources. I don't know how to work around this. These
companies should be coaxed into forming their drivers
properly, esp. now that there are "universal binaries"
to worry about.


Switching topic again. The ugly internal name UID seems
to be based on the card's PCI address. This could
change if I (a) remove or add a card, any card, and/or
(b) move this card to another slot. The UID might be
different between anyone's machine even if in the same
slot. The UID might be different between OSX releases
even in the same machine without changing anything else.
I also have M-Audio's Firewire 410 box but won't use it
for now (their drivers are ""weird"" here). I used to
have two different USB modules from them too, and gave
them away to friends. ;) I can only imagine the
nightmare this is causing to have jackit support them.
And so on and on... Oh yes I saw the post someone made
to this list, that some USB modules can be
little-endian, but there's no way to tell, apparently no
(standard) flag in the data-stream (USB-level) will tell
its endian-ness, you just only have its UIDs to go on.
And so on and on...

Does Apple provide source code of System Prefs / Sound
Panel? It would be interesting to see how it handles
these things. I suppose Apple wants us to learn from
studying HALLab.


Oh well... The --help idea is very good, and --verbose
from Kito is good also... anything to help a
non-technical end-user esp. who won't have Developer Kit
(HALLab) installed. :)


Thank you (everyone) very much for talking about this.





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Stéphane Letz
2005-12-20 09:17:40 UTC
Permalink
Post by s***@hush.ai
Hi,
Post by Stéphane Letz
Post by s***@hush.ai
[...]
So, technically jack_coreaudio presently wants everyone
to look up the plain UID to use as the --name parm no
matter what (on-board, third-party, etc.), or leave off
--name to use the Sound Panel Prefs default device.
Which method is easier? ;) I'd like to work on
instilling the user-friendly code inside jack_coreaudio
itself.
The main reason to switch form the "user friendly"
name to the "ugly" internal one was a localization
issue. On french system for instance "Built-in
Audio" appears as "Audio int&#65533;gr&#65533; when you use the
kAudioDevicePropertyDeviceName to get the driver
name.
The localized version only appears is the process
that use the kAudioDevicePropertyDeviceName is
itself localized, thus the JackPilot would see
"Audio int&#65533;gr&#65533;" when the jack coreaudio_driver would
like to see the non-localized one "Built-in Audio".
I asked last year on the coreaudio-mailing list how
to *always* retrieve the non-localized version but
it appeared complex to handle, at least more complex
to switch to the "ugly" internal name that remains
the same everywhere.
In any case there is a translation needed at some
point: a french user would use Audio/Midi setup to
look at the driver name (or system preferences
/Sound), see "Audio int&#65533;gr&#65533;", use jack -d coreaudio
-n "Audio int&#65533;gr&#65533;"... and it would fail...
There is no way for the french user to retrieve to
non-localized version but to use HALLab that (right
now) display the non- localized version...this is
tricky also.
Now the coreaudio_driver use the plain UID (not the
model UID)
So the "solution" I would see is to improve the
--help stuff of the coreaudio driver, to that all
possible internal are displayed (possibly associated
with the user friendly non-localized version) and
document the issue to the user.
What do you think?
Stephane
Yes that sounds excellent (I saw your later post on
this, too).
I just had an idea, wonder if the following might help
I've watched the development of MPlayer for a long time
(over a year). This is the 'main' project, not the OSX
branch of it, but the latter does affect the main code.
By using a couple compile-time switches in its configure
script, the cmd-line mplayer can act as if it knows
about a bundle, but itself is a plain cmd-line app
(flat). Even if installed under /usr/local/bin i.e. not
inside the MPlayerOSX bundle, invoking mplayer will
cause Dock to show a generic grey icon (Unix file) as if
it was an OSX'ized app. But by putting this flat binary
inside a bundle, it should auto-magically respond to
actions such as Drag-&-Drop and be able to receive
..app-style arguments etc. plus (I think) to know about
Resources that translate messages (I think, can't test
it here ;) ).
Further, in order to build MPlayerOSX, it needs to have
the binaries made from the main MPlayer project. This
way we don't need to have multiple src trees of the main
code. (This is something I've never been sure about,
e.g. upon what version of jackit is jackosx and your
JackdMP based -- is it on 0.100.0 or 0.100.7 or even cvs
etc.)
So maybe jackd could follow suit, and jack_coreaudio
inherit these qualities from its caller -- i.e.
hypothetically, when jackd is merged into the jackosx or
_your_ GUI bundle, it should auto-magically become an
..app-style program and be able to handle localisation by
itself. But we have only one main code-base which is in
the jackit project. If after jackd becomes
knowledgeable of bundles and language resources etc., it
could also support writing & reading Preferences in the
standard OSX way, too -- then your GUIs would truly
become standardised. Your --help feature could actually
set those Prefs on behalf of the end-user.
Now to switch to another issue. I checked the files
installed by M-Audio. Nothing is localised, I see no
Resource subdirs anywhere. Instead, I think M-Audio
distributes different language drivers depending on in
which country their web-site is located. That means the
strings are hard-coded within the binary, and not in
Resources. I don't know how to work around this. These
companies should be coaxed into forming their drivers
properly, esp. now that there are "universal binaries"
to worry about.
I should have a look at some point....
Post by s***@hush.ai
Switching topic again. The ugly internal name UID seems
to be based on the card's PCI address. This could
change if I (a) remove or add a card, any card, and/or
(b) move this card to another slot. The UID might be
different between anyone's machine even if in the same
slot. The UID might be different between OSX releases
even in the same machine without changing anything else.
I also have M-Audio's Firewire 410 box but won't use it
for now (their drivers are ""weird"" here). I used to
have two different USB modules from them too, and gave
them away to friends. ;) I can only imagine the
nightmare this is causing to have jackit support them.
And so on and on... Oh yes I saw the post someone made
to this list, that some USB modules can be
little-endian, but there's no way to tell, apparently no
(standard) flag in the data-stream (USB-level) will tell
its endian-ness, you just only have its UIDs to go on.
And so on and on...
Here is the description of kAudioDevicePropertyDeviceUID I'm using:


A CFString that contains a persistent identifier for the
AudioDevice. An
AudioDevice's UID is persistent across boots. The content of
the UID string
is a black box and may contain information that is unique to a
particular
instance of an AudioDevice's hardware or unique to the CPU.
Therefore they
are not suitable for passing between CPUs or for identifying
similar models
of hardware.

Maybe it changes if you change the slots, I cannot check here... but
i did not find a better property to identify a given device in any
context. Other one available seems even weaker.
JackPilot strategy in saving/restoring preferences is that it will
display the preferences window for the user if it cannot find the
audio device and/or restore other preferences (sample rate, in/out
channels....) I don't think i can do better in this area...
Post by s***@hush.ai
Does Apple provide source code of System Prefs / Sound
Panel? It would be interesting to see how it handles
these things.
System Prefs / Sound display the localized version of the de device
name.
The source code is not available.
Post by s***@hush.ai
I suppose Apple wants us to learn from
studying HALLab.
HALLab display the non-localized version.... but it i manually add a
French.lprof folder into its ressources, then it start displaying the
localized version.
Post by s***@hush.ai
Oh well... The --help idea is very good, and --verbose
from Kito is good also... anything to help a
non-technical end-user esp. who won't have Developer Kit
(HALLab) installed. :)
Yep

Stephane



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

Loading...