 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
4.154.37.232
In Reply to: Re: Can use DVD-Player with Benchmark DAC ? posted by Bertie_Livingston on July 28, 2006 at 13:55:11:
You believe all transports sound the same? Man you have got to be kidding!LOL
"Boosting signal is of no consequence". This is one of the reasons transports sound different. If you'd tried it... we probable wouldn't be having this debate.
I once thought the same...after some gear experimentation. I know now that the transport does make a difference..better or worse.Good listening
Follow Ups:
You believe all transports sound the same? Man you have got to be kidding!LOL
"Boosting signal is of no consequence". This is one of the reasons transports sound different.Digital signals are independent of their strength as long as they
make it to the other side safely. Amplifying a digital signal only
risks of damaging the other side's input ports.Maximizing the signal prior to conversion to digital (or rendition
into a downmix) will improve using all of the dynamic space in the
16 bits of the CD-Audio format, but that usually happens in the sound
engineer's studio, who is deciding which bits get onto the CD you
bought at the store. That isn't anything you can change at home.If you'd tried it... we probable wouldn't be having this debate.
I once thought the same...after some gear experimentation.
I know now that the transport does make a difference..better or worse.Sure, but some other factors have changed. You might have used the
internal DACs of the drives, or the drives might not be bit accurate
but prefer to apply some "beautification" algorithms, or something
happens on the S/PDIF to the DAC like varying forms of jitter. You
cannot possibly have heard a difference in the bits if the bits
themselves were identical, so it must have happened somewhere else.
What is there to laugh about? I'm not laughing at your views, which I consider absurd. Of course all decent transports sound the same if your DAC is immune to jitter. This is basic engineering.
HowdyThere is no such thing as a DAC that's imune from jitter. They all have varying amounts of jitter rejection and each of these jitter rejection techniques has strengths and weaknesses and (depending on the jitter input) different audio artifacts from jitter.
It is the case that DAC makers are taking jitter more seriously and that's great for all of us. But jitter imune is like RFI imune, it doesn't exist but some get closer than others.
The Benchmark DAC uses asynchronous sample rate conversion to get rid of jitter. This changes the bits from play to play of a disk depending on the jitter. So much for your arguments on the other thread about bits-is-bits and that the transport doesn't matter. Changing the transport will change the bits being converted.
Here's yet another discussion of this where you can read John Atkinson's take on it: http://www.audioasylum.com/audio/general/messages/442937.html
-Ted
I am not convinced that you are correct about the Benchmark using conventional ASRC. This is what their website says:"UltraLock™ technology totally isolates the conversion clock from the digital audio interface clocks. Jitter on a DAC digital audio input, or an ADC reference input can never have any effect on the conversion clock of an UltraLock™ converter. In an UltraLock™ converter, the conversion clock is never phase-locked to a reference clock. Instead the converter oversampling-ratio is varied with extremely high precision to achieve phase-lock to the reference clock."
I think the last sentence provides the clue as to how it is done.
HowdyDid you see Andy's post http://www.audioasylum.com/audio/digital/messages/120481.html ? The ASRC chip is certainly used for it's intended purpose.
Further "the conversion clock is never phase-locked to a reference clock. Instead the converter oversampling-ratio is varied with extremely high precision to achieve phase-lock to the reference clock" is essentially the definition of ASRC.
And FWIW you can read Lavry's opinion of this technology: http://www.lavryengineering.com/asynchronous_testing.html
-Ted
The question is how your ASRC is implemented. While interpolation in the time domain results in low-pass filtering (ie. in the frequency domain), low cutoff frequencies can result in very good jitter attenuation, which obviously the Benchmark has.I don't think Stereophile's jitter tests (Miller Audio) are prone to the theoretical shortfalls mentioned in the Lavry paper.
I have to run now, more on this later.
HowdyRead the AD chip's spec. It's as I stated.
-Ted
Yuck!!!Thanks for letting me know.
Although if you do ASRC, you might as well upsample everything to a single rate (either 96 or 192) and then you can implement a really good upsampling filter (I'm not sure what chip the Benchmark uses for ASRC though - I haven't been too impressed with the ones I have heard)
HowdyThat's what I presumed was the biggest advantage of ASRC DACs: namely that they could optimize everything down stream for a single sample rate (especially the reconstruction filter...)
-Ted
"That's what I presumed was the biggest advantage of ASRC DACs: namely that they could optimize everything down stream for a single sample rate (especially the reconstruction filter...)"That's maybe the only advantage.... I personally think asynchronous sample-rate conversion is the single-worst "technology" to be introduced to the audio world since digitized audio was introduced roughly 30 years ago.
Problem with SRC is that I can usually hear it - it seems to slightly "flatten" the sound. I think most people like it because the additional filtering makes the sound seem "smoother" but at the expense of losing PRAT.I would like to see a really good ASRC and digital filter implementation - lots of taps, and operating in IEEE double precision :-) Presumably the hardware for doing this is around the corner :-)
What is PRAT?
HowdySometimes called the Boogie Factor. One very useful ways to compare systems or components in my experience is to watch people's toes as they listen. If they aren't tapping their feet something is wrong.
-Ted
Does this mean that certain audiophile systems may be unable to maintain the music's rhythm or pace? How is that possible? I must say I have never encountered that.
HowdyIt's a relative thing (like slow or fast systems.) I don't have enough direct experience to categorize which systems or features screw up PRAT (tho I'm sure a search will yield some fruit and some Naim fanatics may say that anything but Naim messes up PRAT :)
My first exposure to it was a home brew speaker demo. One of the attendees was Jennifer Crock (of Jena Labs) with a couple of test masters of a recent recording. I didn't notice anything in particular when she played the first one, but when she switched to one that had been burned with different parameters (I don't know which parameters, but she said that both were error free and bit identical) I noticed that the people in the room stopped tapping their feet and that conversation got louder. She went back to the first disc and people started listening to the music more and the foot tapping started up again. Like Spock she just said "Interesting."
Another time we had the 5 box Esoteric SACD player at mikel's house and were comparing it to the EMM Labs DAC6e. After a lot of A/Bing I chanced to put in a Shaggy SACD. When played on the DAC6e everyone was smiling and my wife was dancing in the back. On the Esoteric the smiles disappeared and we didn't finish the track. The track just didn't have the same emotion, the rhythm was off, heck it was even hard to force your feet to start to tap.
One of the reasons I like a "fast" system is that it is less likely to mess with the PRAT, if a drum hit isn't sharp it's more ambiguous exactly when it happens at.
Christine's point (if I can put words in her mouth) is that the varying low pass filtering of ASRC takes varying amounts off of the tops of impulses smearing them in time and thus causing loss of timing (PRAT).
At times I hear loss of PRAT too, tho I know from personal experience I hear it less than Christine and so I resort to observing my need to tap my feet and watching others.
-Ted
You can ask most DJs in clubs that cd technology messes with the PRAT.
If you want people pratting all night you need vinyl!I guess there is a problem inherent to measuring your equipment with
PRAT appreciation:The more precise your equipment renders what is on your CD-Audio, the
more it will reveal how cold and ugly 44.1 kHz are. That's the truth.
So the more precise your equipment is, the less PRAT it will have.You need an imprecise system to maximize PRAT!
What is it you want. A system that shows you the truth, or a system
that makes you feel good? You can't have both with CD-Audio.But you can move on to SACD, DVD-Audio etc. I guess.
N-rays could not be detected by any scientific instrument, only by human beings. The sign of N-ray presence was a subtle increase in brightness of a dim light source in a dark room. Humans were the only reliable detection device. Unfortunately, it turns out that N-rays didn't exist;it was all in Blondlot's head, and in the minds of people who believed him.I like Don Morrison's take on the subject.
http://morrisonaudio.com/morrison_donsview.htm
HowdyIndeed there is a big difference between the PRAT on CD, SACD and vinyl and I do mostly listen to SACD.
I disagree with your characaterization that you need an imprecise system to maximize PRAT tho. I strive for PRAT and accuracy and achieve a petty good mix.
-Ted
Undoubtedly some systems are more involving than others, but I would never call it PRAT.The amount of alcohol ingested prior to listening has a greater effect on tapping than most other variables, BTW.
HowdyI call it PRAT when it's the timing that off, involving is another thing. The only difference in the two bit identical CD case was clearly timing.
None of us drink :)
-Ted
"I call it PRAT when it's the timing that off, involving is another thing. The only difference in the two bit identical CD case was clearly timing."You are saying that a few Hz off in a 44.1 KHz sampling throws off the music's rhythm?
Hehe.. Well I can theorize what he means.. When I listen to
unmodified cd-audio digitally amplified without upsampling
or anything I do understand what so many say about digital
sounding cold.It is enough to have some upsampling in place to smooth that
coldness away. It is a musically correct step since the
edginess of 44.1 kHz is unnatural, and necessary anyway since
we like to apply our room correction filters before going analog,
and you wouldn't want those algorythms to operate on a 44.1
level. Far too harsh.Considering this, I can imagine that subtle jitter distortion
probably feels similar. It makes music edgier thus colder.But that's just speculation... ;)
Howdy"Few Hz"? I don't understand what you are asking.
The only difference was jitter and indeed it screwed with the timing enough to take the fun out of the music. When we A/B'ed no one could articulate a difference, but just watching people was quite illuminating. Also trying to tap your toes to one was hard but tapping to the other one was natural.
-Ted
How can jitter "screw up the timing" of music? Jitter produces distortion, not a change in pace that can alter the rhythm of music.
HowdyJitter is a change in the timing of the clock by definition. The question for the skeptical is "How can the ear hear such small changes in the timing?" I don't pretend to know the precise answer, but it's clear that it happens and it's clear that people can hear effects from jitter. I've explained elsewhere how ASRC filtering (which is uniformly implemented with FIR filters) varies form perfect reconstruction to low pass filtering depending on the phase, that filtering smears impulses, i.e. it makes the timing indistinct. In the case of PLLs perhaps the changes in timing that bug people are caused by the changes in the freq of the clock (a little fast then a little slow...)
Anyway I just suggest you keep your eyes open for toe tapping when you try various tweaks, audition equipment or visit your local audio club.
-Ted
" it's clear that it happens and it's clear that people can hear [pace and/or rhythm] effects from jitter"I don't think this is clear at all. Tempo variations are measured in time units several orders of magnitude larger than any reasonable jitter can produce. There is no possible explanation in that regard that I can think of, other than jitter distortion affecting involvement with the music. Toe tapping is not an automatic reflex resulting from tempo. It is a sign of the listener's psychological involvement with the music. That is why it varies from person to person, as well as with the listener's predisposition at that precise moment.
HowdyWell, even if you don't believe it watch for it :)
-Ted
nt
HowdyThere's essentially no way to avoid low pass filtering when the phase is far off and this isn't rare since the phase is always changing in any steady state setup unless the clocks are perfectly synchronized (think "beating".)
There are lots of optimizations in ASRC (i.e. zeros in the coefficients used to upsample and downsample) so it's not as bad as it first appears. Did you see the paper in the other thread? ( http://www.iet.ntnu.no/courses/fe8114/slides/upsanddownsofasrc.pdf )
Also you might find http://www.iet.ntnu.no/courses/fe8114/files/Rothacher_Phd_1995.pdf interesting.
-Ted
Sounds like even with optimization, the computational power required is substantial. So maybe the hardware necessary isn't around the corner after all :-(Given that today's flagship DACs use a "hybrid approach" consisting of multi-current segmented sigma delta, an interesting design would be to have a DAC that accepts a hybrid signal natively (ie. combination of PCM and sigma delta as the input).
that way, the DAC itself does not oversample or perform sigma delta modulation, and allows the implementer to do the digital filtering. This way, it avoids the "double filtering" that today's upsampling implementations seem to require (upsampling by an external filter, followed by oversampling and sigma delta conversion at the DAC).
No no the necessary hardware already exists, only to completely
different purpose!The problem of transferring digital data completely loss-less
has been solved by any computer interface in existence, since
computers need to have loss-less data transfer to do ANYTHING
useful with it.Jitter exists in computer circuitry too, but it has been
solved technologically.In audio however occasional erroneous bits weren't considered
harmful and smoothed away by resampling and such. By now it
is becoming evident that we no longer want to accept that.
We expect the same data reliability that computer technology
has, so we need to use other interfaces than S/PDIF.
My point is that some modestly priced DACs have as good if not better jitter rejection than other very expensive ones. This is clearly seen, for instance, in the Stereophile measurements of the Benchmark DAC, just to give one example. I do not think you are fully characterizing the jitter rejection mechanism employed by the Benchmark, and to my knowledge they do not disclose exactly what it is. I understand it uses a buffer and probably some modified PLL. That can work quite well in practice, as it does on the Lavry units. The second point is that for all intents and purposes this makes the transport almost irrelevant. people who want to spend a fortune on transports can do so but I personally don't see the need.
The Lavry and Benchmarks use entirely different schemes to handle jitter. In the Lavry the data merely go into a buffer and are released in synch with its internal clock. The data are unchanged (bit transparent).This is far different than the Benchmark system which can result in a different data stream depending on the jitter (not bit transparent)
Here is a case where standard industry measurements (like J. Atkinson's) don't tell the whole story. [Where have we heard THAT before?] In practice the Lavry seems much more insensitive to the player and cables that feed it than is the Benchmark.
Mel
PS: Latest comparison of the two, By the way is at:
. . . . JUST started requiring registration. Could be that the article comparing the Benchmark and the Lavry generated too much traffic.
HowdyIf you read between the lines at the Benchmark site it's obvious that they use ASRC. It's highly unlikely that they use a PLL since they upsample at the same time and they accept input from multiple sources all of which have different clocks, so how the heck are they going to not get behind on one clock while they get ahead on another? Also as I mentioned earlier John's post (actually his refinement a little further down the thread: http://www.audioasylum.com/audio/general/messages/443413.html ) agrees with my characterization.
-Ted
nt
HowdyIf data is coming in at different rates on different DACs inputs there is no guarantee that any particular data source will ever catch up with another. In fact the longer you run the further they are expected to drift from one another. To handle this the Benchmark DAC in effect resamples each input data stream using the output clock, this allows them to have multiple linked DACs running with perfectly synchronized outputs (which is good.)
This resampling is done with ASRC which we are discussing on another thread.
-Ted
As I mentioned the drift is minimal because clocks are very accurate in practice. You don't need a huge buffer to make this in practice negligible. Ideally you would have a large enough buffer and pay attention only to one clock next to the DAC. I think Chord had a unit that did that.
HowdyIt doesn't matter how accurate the clocks are, if they aren't the same clock or locked clocks (which is impossible with multiple sources) they will drift and if you don't use a PLL or ASRC you will get clicks and pops or worse complete buffer overrun or underrun.
-Ted
Uh.. but how small does a buffer have to be that it underruns or
overflows in any short time period?If your system is more or less sane, output should start at say
50% buffer level, then it may grow or shrink, but if chosen big
enough it should take days until the first buffer error happens.I mean, the clocks are supposed to have the same speed. Even if
this is slightly not the case, buffers are big enough to compensate
it up for a seriously long time period.It may be a good idea to shutdown your systems after listening
to music, profoundly to the contrary of the "burning in"
principle we discussed in the other thread...Does this problem really exist? I have never heard of that, which
may suggest this is just a theoretical problem.
HowdySure it's a problem, jeeze just do the numbers, take the accuracy of a typical crystal, take assume one is at it's max deviation on the high side and the other is at it's max on the low side. Then see how many samples at 44.1k / sec can go by before you are a sample off, you might be surprised. In real life a transport doesn't know if it's input is coming from an ipod, a CD, streaming radio, a digital audio workstation looping data... You can't just buffer up a disc worth of data and quit. DACs have to work with any sane input. It's a real problem.
It's pretty arrogant to assume that if you haven't heard of a problem that it doesn't exist: The reason you haven't heard of the problem is that all sane DACs use PLLs, ASRC or the topology I described to avoid this (and other) problems, not the simplistic "bits-is-bits" view that so many computer-savvy but real-world-engineering-nieve people seem to have.
-Ted
P.S. we didn't discuss burn-in on another thread, I gave my opinion and left your response (along with some other nieve responses) uncontested.
Is "nieve" supposed to mean naive?Discussion on this topic is continued on
http://www.audioasylum.com/audio/digital/messages/120634.html
Hehe, is "nieve" a word in your spell checker?
Creative! :)
HowdyIt's the Google toolbar spelling checker. Pretty handy in general. The collaborative filtering is useful but some extremely common misspellings are allowed.
Conversely two words that passed earlier ("dont" and ironically "nieve") don't pass now. Another feature of Google: you don't always get the same server and hence you may get slightly different answers depending on the last database update...
-Ted
I have never heard a click or a pop from any of the DACs I have recently heard. Have you? perhaps you are thinking of glorious vinyl! ;)
HowdyNot the way you apparently think they do.
-Ted
What are you referring to?
Howdy"As I mentioned the drift is minimal because clocks are very accurate in practice. You don't need a huge buffer to make this in practice negligible."
In fact this slow drift will either cause clicks if you don't manage it with a PLL of ASRC. We've beat to death the effects of those, but I should highlight that clocks that drift very slowly relative to each other cause the ASRC to slowly go thru all possible phase offsets and hence all possible different interpolations of the data. Sort of a worst case for hearing the results of ASRC.
-Ted
You can also put a buffer in between and adjust the speed of the clock periodically. There will be no clicks. My point was I never said anything to the contrary that a PLL or ASRC wouldn't do the trick.
In a well implemented design the adjustments will be made to accommodate the drift without audible effect. Lavry designs use a buffer and an adjustment (+ or -) is made to the clock in .1ppm increments approx. every 15 seconds.No clicks.
Mel
nt
"As Christine and Ted have mentioned, slaving the source to the
DAC clock is the best way of minimizing jitter"
I would have to disagree, even if you have flags telling you where the clock/s should fall. This was implemented in S/PDIF many moons ago too. :) Also, today's CD/SACD and Universal players need much more than ONE clock, and even if it is a 44.1K product only, it is still done with PLL/s. Referencing this PLL (which usually has enormous amount of jitter due to its design) with an external clock (from the DAC) will reduce the problem, but will not solve it. Not to talk about the fact that most of the clock syncing circuits today are based on VCO or VCXO.I tried to explain this to Christine not long ago, but she didn’t get it. For example, the 44.1K ONLY Sony SCD-1/777ES has TWO PLLs inside. :)
Not that PLLs are bad! In fact, some later ones feature considerably lower jitter, may be the lowest obtainable (if synchronous operation is required, of course). :)
Regards,
Alex
*** I tried to explain this to Christine not long ago, but she didn’t get it. ***Or maybe you are the one who doesn't get it.
It is possible to design a CD player with only one clock (for audio that is), and NO PLL.
For example, my player switches between two clocks, one for 44.1, 88.2, 176.4 family , and the other for 48,96,192 family. Absolutely no ASRC or PLL required for any media, including CD.
PLL imposes a jitter floor of at least 100ps. If you really care about minimising jitter, you need to get it down to below 20ps at the DAC. Modding an existing player won't get you there - most of them (as you pointed out) has a PLL in there somewhere.
In fact, it reads the CD completely asynchronously. Oh, I'm sure there is a PLL in there somewhere, but not in the audio playback chain.
Now you admit it! :) But of course there is a PLL somewhere in the chain! There is no digital playback device made yet that does not have PLL somewhere, and that is all the point I wanted to make. :)Speaking of jitter, I am clocking my DSPs with less than 50pS and my DACs with around 1pS.
:)
Regards,
Alex
*** But of course there is a PLL somewhere in the chain! ***No, there is no PLL in the digital audio playback chain, as I've tried to explain. However, given that the drive is an off the shelf PC DVD drive, I'm sure there is PLL in there somewhere in the mechanism, but it's irrelevant.
The data from the CD is read into a buffer completely unclocked (ie., non real time). So a PLL is not required. In fact, generally the drive reads the audio data much faster than real time but sporadically, to allow it to reread the data when it encounters errors etc.
So, yes, there is at least one "digital playback device" that does not have PLL anywhere in the audio path. That was the point I wanted to make :-)
"No, there is no PLL in the digital audio playback chain, as I've tried to explain. However, given that the drive is an off the shelf PC DVD drive, I'm sure there is PLL in there somewhere in the mechanism, but it's irrelevant."Irrelevant? Not that I think so!
"The data from the CD is read into a buffer completely unclocked (ie., non real time). So a PLL is not required. In fact, generally the drive reads the audio data much faster than real time but sporadically, to allow it to reread the data when it encounters errors etc."
This is the case with just about every Universal player on the market today, including $150 examples. Your 3910 reads at x10 and does the same things. Also, there is no such thing as “unclocked” buffer. The SDRAM is clocked by the DSP which is referenced by the PLL-ed master clock. :-)
"So, yes, there is at least one "digital playback device" that does not have PLL anywhere in the audio path. That was the point I wanted to make :-)"
No such thing yet, it is impossible. And actually, the PLL for the clocks is not that bad at all (especially when it comes to new PLL devices) compared to the much slower PLLs locking the servo in your reader/transport. This Servo, BTW, is also clocked by the PLL of the DSPs. Do you really think you can "correct" an error that has already occurred? “Bits are bits”, eh? :-)
And please don't tell me all this talk is for computer based audio with EMU1212 card! :-) All I use this one for (and heavily upgraded) is for its world's best ADC. The CS4398 DAC I completely remove. Been there done that long time ago with the CS4398. At that time no one else used it. :-)
:-)
Regards,
Alex
.
The command I am sending to the drive is a "Digital Audio Extraction" command (which results in audio data being transferred as fast as the drive can extract it). A "C2" error is flagged if the data contains errors, allowing the read command to be retried.This is essentially the same principle as the "Exact Audio Copy" (EAC) program, and as for EAC it's important to choose a drive that does not cache audio data (otherwise the drive might get lazy during rereads and simply spit out the same errorneous data).
The DAC is driven directly off a clock with no intervening PLL stages. There is another buffer in front of the DAC, and audio samples are extracted from this buffer at exactly the same rate as the DAC in order to feed the DAC with minimal jitter.
Choosing buffer sizes is quite important, as well as avoiding memory access contention (between the transport buffer trying to fill the DAC buffer, and the data being extracted from the DAC buffer).
Because the data is read from the drive at faster than normal speed, it potentially allows me to do clever things like variable speed playback (ie. fast forward will timestretch and pitch shift the data) but I haven't bothered implementing those features yet.
But cross fades during track skips would be nice (you get an uninterrupted flow of music even when skipping tracks).
HowdyI was referring to designs that don't use PLLs (nor ASRC) at all, but instead have separate crystals for each mode, for example, for 44.1k and it's multiples and another for 48k and it's multiples. After all there is nothing wrong with having the proper crystal clock for each freq. Tho I don't know specifically who does or doesn't do it. (Does the Sony DVP-S9000ES?)
I don't know what you mean by your S/PDIF clock statement, if you are referring to using an extra S/PDIF connection to send the clock from the DAC back to the transport, yep people have done that for a while, but that's one implementation of what I was talking about. If you were referring to Ed's patent about using only the bits in the header info of the protocol of S/PDIF that never change as the bits to synchronize to for running a PLL, well that is clearly inferior to sending the clock explicitly back from the DAC to the source to gather up the bits... Even a good PLL is inferior to no PLL. (Of course implementation is everything and can swamp all of this technical stuff.)
-Ted
P.S. Good to see you around too.
Hi Ted,The S9000ES has two clocks near the VC24+ chip (45 and 49M), but also 3 PLLs to provide clocks for the DSPs on the transport.
Even if you send a reference clock from the DAC to the transport, it still hits PLLs on the DSP board. So the clocks used for the PCM and DSD Decoders come from PLL. That is also the case with Philips.
What good is a low jitter clock next to a DAC if this same DAC is fed up data and clocks from a DSP that is being clocked with large amount of jitter? I would even say that with the bitstream DACs (delta sigma) the jitter is not of such a big concern at all. That DSP needs the precision clock, not the DAC. As you know, the DSD1700 DAC does not even need master clock since it is nothing more but FIR. This applies for all the latest BB DACs when in DSD mode.
Regards,
Alex
HowdyIt all depends on where the data buffers are doesn't it? I don't know the chips involved and how much internal buffering they have without digging out a schematic and data sheets...
Anyway, none of these devices do the sane thing of sourcing the clock from the DAC (or other low jitter single master clock) to the transport and then back to the DAC like, say the Esoteric, Meitner, most pro audio gear, etc. with no PLLs, etc. Which was my point on the thread that John was talking about. You'll never convince me that PLLs (or their moral equivalents) and/or ASRC make any sense compared to the single (active) clock (no PLLs, etc.) setup. This is just common sense and not hard to implement (it just takes more wires than people want), unfortunately it not very common in consumer audio gear.
-Ted
...
...It's a pleasure to see you around Ted!:)
Regards,
Alex
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2025, Audio Asylum, all rights reserved ]
