Hello all,
This has stirred up more interest (also off-list) than
I ever imagined it would !
OK, beers will go to (in no particular order)
Niels: his comments on ADC/DAC reference voltages
provide the key to understanding what happened.
Veronica: for the most to-the-point one-liner.
Florian: (off list) who got it right in the end.
I guess that at least initially all of you put the
blame of card X - either it's crap or it's defective.
But the real culprit is card A, even if it did show
quite well in the loopback test. And what happens is
100 Hz (rectified power grid 50 Hz) ripple on the DAC
and ADC reference voltages, both derived from the same
source.
Most audio ADCs and DACs have two reference voltages
(or one, and then the second is derived internally).
In many cases these are the voltages that correspond
to the min and max PCM values, and even if that is not
the case the conversion factor of the ADC or DAC depends
linearly on these voltages. If they are not well filtered,
any fluctuations do generate AM, and the effects of the
same eror on a ADC and DAC will cancel out.
Cancellation also occurs if the sample clock (if shared by
ADC and DAC) is modulated, but here the effect is delay
modulation, which for a single tone translates into phase
modulation proportional to the frequency of the signal.
Since in this case the sideband levels do not depend on
the measurement frequency, the sidebands are not the
result of clock jitter.
So Veronica is quite right: you can't trust a loopback test.
And if, as in this case, the variations are the result of
mains hum, you can't even trust a setup of two cards using
the same mains power (although exact cancellation as in this
case would be rare).
It is also true that you have to be very careful when using
a low-fi card to test a much better one. In this case the
only purpose of the USB card was to provide a calibrated
analog level, which is required for e.g. EIN measurement.
The card is portable so I can easily take it to the lab and
calibrate it against a high precision certified RMS meter
which I can't take out without first filling out a hundred
forms and then waiting two weeks.
Meanwhile I did measure the signal quality of card X using
a *decent* generator - it is extremely good.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Hi,
I'm trying to find a simple host for my LV2 plugin that allows both midi in
and out, and also allows you to control plugin parameters.
I've found lv2_jack_host, which allows my port configuration, but doesn't
seem to allow you to change the parameters, and I've found lv2rack and
zynjacku, which allow you to change plugin controls, but don't seem to allow
nonstandard input/output port configurations.
Any suggestions would be nice.
Thank you
Jeremy
Hi linux-audio peoples,
I want to announce my new and fun and useful python script -- I call it
'jackctl' -- it basically is a frontend to the jack tools 'jack_lsp' and
'jack_connect'. It's like 'qjackctl' , but since it's command line, no 'q'
!!!
get it here:
http://www.akjmusic.com/software/jackctl20100526.py
Why would I embark on writing such a script? Who would want to use this?
You'll want to try this if one or any of the the following apply:
1) You don't want to have to install the entire QT toolkit for a single
program.
2) If you like the command line, use a console, but still use jack often
enough
3) You've used jack and 'jack_connect' through the command line before, but
hated having to type the full name of the jack ports.
4) You've noticed that 'qjackctl' introduces CPU overhead and xruns you
don't have when you use command-line jack, i.e. you are obsessed with the
lowest possible latency
5) You want a fast, simple interface to connect jack ports that is even
faster than a GUI---no need to point the mouse, just type two numbers and
go!
It's very simple. All you need is Python (and who doesn't have that on their
machine). You put the script in your PATH, or link it/rename it, making sure
it's exectuable. When you run it, you'll see a list of current numbered jack
ports, and you can connect them by typing two numbers separated by a space.
You can disconnect them by typing 'd' then the two numbers separated by a
space. No hassles, and a nice feature is that it will protect you from
making ear-blasting feedback connections. It's even quicker than qjackctl,
b/c it takes more time to point your mouse at the ports in the GUI and then
click 'connect' than it does to type two single-digit numbers and then hit
return, yes?
Let me know how you like it...I'm interested in reasonable feature requests.
One potential TODO would be to make this script have a user-friendly way to
start the jack daemon, but for now, I do that manually....
Enjoy, comments welcome!
--
Aaron Krister Johnson
http://www.akjmusic.comhttp://www.untwelve.org
Olivier Guilyardi wrote:
> On 05/28/2010 07:36 PM, Ralf Mardorf wrote:
>
>> Folderol wrote:
>>
>>> On Fri, 28 May 2010 19:20:54 +0200
>>> Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
>>>
>>>
>>>
>>>> Veronica Merryfield wrote:
>>>>
>>>>
>>>>> You can't trust a loop back test.
>>>>> Any instability or dither on the reference clock of card A (fifo
>>>>> clocking say) is not going to show in a loop back test.
>>>>> Vrnc
>>>>>
>>>>>
>>>> Is Veronica Merryfield the winner?
>>>>
>>>>
>>> I'm highly suspicious of the USB link, but can't quite put my finger
>>> on why.
>>>
>>>
>> Card A is the USB card. For USB there could be several issues, but I
>> don't have knowledge about buffering etc., but I guess it's card A and
>> that there's a "instability" = jitter. I don't know what dither for CLK
>> is. I guess the winner is Veronica Merryfield.
>>
>
> I mentioned the clock problem first ;-) However, I thought it the other way
> around: I said that clocks being asynchronous that would generate artefacts, but
> Veronica seems to say that these are hidden when using a single clock.
>
> That's pretty much the same thing to me :p
>
> --
> Olivier
>
Did you also say for what card? A or X? If so, is Oliver the winner?
Btw.:
Ralf Mardorf wrote:
> Gabriel Beddingfield wrote:
>> On Fri, May 28, 2010 at 12:39 PM, Gabriel M. Beddingfield
>> <gabrbedd(a)gmail.com> wrote:
>>
>>> The 100 Hz (being 2x 50Hz, the power freq. in Italy)
>>> suggests that it is probably related to some manner of
>>> power supply. However, I have no theory why we're
>>> getting 2x 50Hz (and I think I need one :-)).
>>>
>>
>> Doh! When the AC wave is rectified, it results in a signal that is 2x
>> the freq. because the negative part gets inverted. That's why we see
>> 100 Hz instead of 50 Hz.
>>
>> -gabriel
>>
>
> On card A or X?
> Why AM and not additive signals?
Is the jitter caused because of residual ripple?
Summarized:
Residual ripple for the DC could cause clock jitter and this for card A.
On Fri, May 28, 2010 at 04:09:42PM +0200, Olivier Guilyardi wrote:
> > <http://www.kokkinizita.net/linuxaudio/quiz.html>
>
> Well, it looks to me like this is caused by the fact that the audio cards clocks
> are not in sync. When you loopback card A with itself, both input and output are
> sampled with the same clock. But when you plug the output of card A into card X,
> you're dealing with two clocks which are not synchronized, and that result into
> these "artefacts". If I'm right then you should observe some /similar/ issues
> when repeating the experience with the cards inverted.
The clocks don't matter, as the connection is via an analog signal.
(sorry, no beer !)
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Related to my last reply to your question about "the tiling problem"
vs undecidability...
Ever since they started putting out relevant articles for computer
scientists (in the last year), the American Math Society monthly
"Notices" has gone from dull to fascinating; in the spirit of
open-source, all the articles are available free and online.
The latest ( http://www.ams.org/notices/201003/ ), focusing on
Cryptography issues, has an excellent article that goes into the
tiling problem in great detail -- and yet is a very clear explanation
(IMHO) that isn't predicated on incomprehensible (to the general
public) mathematical formalisms.
http://www.ams.org/notices/201003/rtx100300343p.pdf
Can't Decide? Undecide! by Chaim Goodman-Strauss
See also: http://www.srcf.ucam.org/~jsm28/tiling/
I've posted previously about other excellent articles in a previous
issue "Mathematics and the Arts" ( http://www.ams.org/notices/201001/
) with a though-provoking introductory essay by Sir Michael Atiyah :
> In the broad light of day mathemati-
> cians check their equations and their
> proofs, leaving no stone unturned in
> their search for rigour. But, at night,
> under the full moon, they dream, they
> float among the stars and wonder at
> the miracle of the heavens. They are
> inspired. Without dreams there is no
> art, no mathematics, no life.
Niels
http://nielsmayer.com
PS: I think the "tiling problem" is actually a direct analogy to music
making... which involves fitting together "tiles" (musical passages,
patterns, etc) that are highly constrained in terms of "geometry"
(pitch, key, time-signature, BPM, starting and ending pitches or
chords). Music making is clearly an "undecidable" problem, which is
where human creativity comes in. Can computers help us "tile" music
more easily and therefore augment our musical creativity??
Hey all,
I've had a little idea that I think might be worth "implementing". This is
it:
Controllers, (in the musical sense like a MIDI controller knob), have always
had a certain
"update" period, ie MIDI cable 31250 baud, or from a MIDI file PPQ's etc..
you the the idea.
What if we were to make a "callback-update" system, where the controller
(read Arduino with a sensor attached)
runs an OSC server, which whenever gets a */<arduinoName>/poll* command,
returns the value of the sensor?
I appreciate that for this example it would seem pretty pointless, as for 1
controller the overhead is gonna be bigger
than the speed gained of just sending it every X ms. Concider a "big" ardour
controller, with moving faders, leds, knobs etc
I think this maybe be a great little system to allow OSC interfaces actually
save the CPU some time polling the MIDI I/O subsystem,
and take advantage of the Send -> Return style thing..
Of course to be all fancy, we could register a "send to" address, so many
programs can access the same device, and have it only update
the correct program, allowing each program handle the OSC messages however
they want to.
Also a */<ardName>/fader ( int ) *could be sent for each fader's position,
*/ardName/knob(int) *.... you get the idea.
Ideas, responses, you've already done this, etc all welcome! -Harry
drew Roberts wrote:
> On Tuesday 25 May 2010 12:10:26 you wrote:
>> drew Roberts wrote:
>>> I have been looking for an EDL capable audio player for a while now but
>>> have not found one.
>> I don't think there's an open-source audio player that does.
>> Mplayer has support for EDL but is using it's own homebrew EDL format;
>>
>> May I ask what you are trying to accomplish?
>
> Sure. and the answer will make much of the complexity below go away for my use
> case.
>
> I listen to some podcasts that I think it would be useful for some other folks
> to listen to as well but people being people, and these people being busy to
> boot, they never seem to get around to listening.
>
> Most of the podcasts are about an hour long.
>
> What I want to do is listen to the podcasts, mark up an edl to pull out the
> parts I think might be most interesting to them and also encourage them to
> listen to the whole thing.
I guess the easiest would be to just use http://soundcloud.com/
You can add comments on the time-line, tag regions and easily share.
see http://soundcloud.com/search?q[fulltext]=podcast for an example.
OTOH, this is not a solution worthy of being mentioned on LAD.
> I would like to give them a link to the podcast and the edl file and let them
> play the audiofile controlled by the edl.
You'll want to use SMIL for that: http://www.w3.org/AudioVideo/
As for creating the SMIL-EDL; that'll be the biggest problem..
Making a SMIL template is a one-time job, but finding a good
audio-player to generate your in/out timecode is an issue. I don't know
if there's a dedicated app for that. Maybe audacity or ardour's
cue-files files can be used as a basis.
I'm pretty sure there'll be a few projects in the not too distant
futures doing this with webm + HTML5.
> So, for what I want, the audio playback does not need to be gapless and nor
> does it need to be accurate to less than a few seconds.
>
> Naturally I can see the usefulness of those abilities for other uses.
>>> So I hacked together ecaedl.pl which work but is very rough.
>>>
>>> More info here:
>>>
>>> http://zotzbro.blogspot.com/2010/05/edl-edit-decision-list-audio-player.h
>>> tml
>> thanks for sharing.
>>
>>> pastebin link here:
>>>
>>> http://pastebin.com/esXJwv84
>> A while ago I went down a very similar road:
>> http://rg42.org/gitweb/?p=sodankyla.git;a=blob;f=scripts/vsession.pl
>> parses EDL (CMX, CMX3600, Final-Cut-Pro format and 3.0.0) into a sqlite
>> database; which can then be used to generate fi. an ardour session.
>
> One thing I want to play with is if I can make the edl files with the
> graphical version of mplayer where I can more easily use the transport
> control so that I can make the edl files on the first listening pass and cut
> down on my time investment. Perhaps it would be better for me to make the edl
> file by hand while listening in another player.
>> The workflow there is offline; meaning there's no real-time playback of
>> the actual EDL.
>> I got a few [filmsound] projects done using these scripts to generate an
>> initial ardour-session where the original sound is synced according to
>> EDL provided by the film (not video) editor, but I did not have the time
>> to go back and clean up the software [yet].
>>
>>> Right now this needs ecaplay from ecasound and perl. mplayer is useful to
>>> create the edl files but they can be created by hand.
>>>
>>> Would any cross playform audio player group be willing to add edl playing
>>> (and creating) functionality to their player? It would make things much
>>> simpler.
>> It's not as easy as it may sound. You'll need to be able to perform
>> reliable sample-accurate seeking over multiple files and play them back
>> without gap.
>
> As you can see from my particular use case, I anticipate only one audiofile
> ever. (I can see that for other uses I might want to work with multiple audio
> files, but not this one.)
>> If you want to support encoded formats (such as mp3) this can become
>> non-trivial very quickly; it can get even worse if the files mentioned
>> in the EDL have different sample-rates (that's very unusual, but hey)
>>
>> I hazard a guess those are basically the reasons why mplayer does not
>> support EDL for audio. mplayer's playlist & video-EDL feature allows you
>> to mix all kind of codecs/formats: seeking to video-frames (with
>> video-frame accuracy is easier).
>>
>> ciao,
>> robin
>
> Thanks for the discussion and input.
>>> (I guess I really need to add in a GPL license section to the file...
>>> soonest.
>>>
>>> all the best,
>>>
>>> drew
>
> drew
>