Reply
 
Thread Tools Display Modes
  #1   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.

I know how this stuff works, but I can't figure this out
right now with my vodka mind.

I'm using Reaper, and I set the sample rate of the ASIO
sound card to 96k. I set the ASIO buffer size to 128 samples.
Reaper reports, in the upper right hand corner, what I assume to
be the latency, as 2.8ms. So I'm doing all this math and can't
arrive at that number myself. What am I missing?

I was thinking, ok, 96000 samples takes a second, so divide that
by 128 and get the number buffers per second. Ok, that's 750. Then
wouldn't the reciprocal be the length of time it takes to empty the
buffer? I get .0013. Where id the 2.8ms that Reaper reports come
from.

Sorry, math is not something that I'm expert at. I know enough
to hurt myself. Thanks for any enlightenment.

Thanks,

Tobiah


  #2   Report Post  
Posted to rec.audio.pro
[email protected] makolber@yahoo.com is offline
external usenet poster
 
Posts: 614
Default A little brain dead right now, so I need math help.

I got 1.3ms also.
Maye there is 1.5 ms latency built on so when you add the 1.3 ms buffers you get 2.8 ms total.

What number does it report when you set the buffers to 0?
Or 1000?

Mark
  #3   Report Post  
Posted to rec.audio.pro
PStamler PStamler is offline
external usenet poster
 
Posts: 882
Default A little brain dead right now, so I need math help.

Some of the latency may come from causes other than buffering. The computer may spend a little time crunching the numbers too.

Peace,
Paul
  #4   Report Post  
Posted to rec.audio.pro
Les Cargill[_4_] Les Cargill[_4_] is offline
external usenet poster
 
Posts: 1,383
Default A little brain dead right now, so I need math help.

Tobiah wrote:
I know how this stuff works, but I can't figure this out
right now with my vodka mind.

I'm using Reaper, and I set the sample rate of the ASIO
sound card to 96k. I set the ASIO buffer size to 128 samples.
Reaper reports, in the upper right hand corner, what I assume to
be the latency, as 2.8ms. So I'm doing all this math and can't
arrive at that number myself. What am I missing?


Get Excel up. If you don't have Excel, use graph paper.

Set # of samples to 2, 4, 8, 16, 32, 64. Plot the
calculated latency vs. # of samples.

It's probably a y=mx+b. where you are looking for b and m, y
is the latency and x is # of samples.

I was thinking, ok, 96000 samples takes a second, so divide that
by 128 and get the number buffers per second. Ok, that's 750. Then
wouldn't the reciprocal be the length of time it takes to empty the
buffer? I get .0013. Where id the 2.8ms that Reaper reports come
from.

Sorry, math is not something that I'm expert at. I know enough
to hurt myself. Thanks for any enlightenment.

Thanks,

Tobiah



--
Les Cargill

  #5   Report Post  
Posted to rec.audio.pro
hank alrich hank alrich is offline
external usenet poster
 
Posts: 4,736
Default A little brain dead right now, so I need math help.

PStamler wrote:

Some of the latency may come from causes other than buffering. The
computer may spend a little time crunching the numbers too.

Peace, Paul


Are there any plugins involved, any processing?

--
shut up and play your guitar * HankAlrich.Com
HankandShaidriMusic.Com
YouTube.Com/WalkinayMusic


  #6   Report Post  
Posted to rec.audio.pro
Luxey Luxey is offline
external usenet poster
 
Posts: 617
Default A little brain dead right now, so I need math help.

четвртак, 11. децембар 2014. 02.26.14 UTC+1, Tobiah је написао/ла:
I know how this stuff works, but I can't figure this out
right now with my vodka mind.

I'm using Reaper, and I set the sample rate of the ASIO
sound card to 96k. I set the ASIO buffer size to 128 samples.
Reaper reports, in the upper right hand corner, what I assume to
be the latency, as 2.8ms. So I'm doing all this math and can't
arrive at that number myself. What am I missing?

I was thinking, ok, 96000 samples takes a second, so divide that
by 128 and get the number buffers per second. Ok, that's 750. Then
wouldn't the reciprocal be the length of time it takes to empty the
buffer? I get .0013. Where id the 2.8ms that Reaper reports come
from.

Sorry, math is not something that I'm expert at. I know enough
to hurt myself. Thanks for any enlightenment.

Thanks,

Tobiah


Latency of OS + Latency of DAW + Latency of (all the ) hardware.
  #7   Report Post  
Posted to rec.audio.pro
William Sommerwerck William Sommerwerck is offline
external usenet poster
 
Posts: 4,718
Default A little brain dead right now, so I need math help.

How many channels are you recording? If you have only one CPU, you can buffer
only one channel at any instant. For two channels and 96k sampling rate, that
would be 2.7ms total.

QED?

  #8   Report Post  
Posted to rec.audio.pro
Mike Rivers[_2_] Mike Rivers[_2_] is offline
external usenet poster
 
Posts: 2,190
Default A little brain dead right now, so I need math help.

On 12/10/2014 8:26 PM, Tobiah wrote:
I was thinking, ok, 96000 samples takes a second, so divide that
by 128 and get the number buffers per second. Ok, that's 750. Then
wouldn't the reciprocal be the length of time it takes to empty the
buffer? I get .0013. Where id the 2.8ms that Reaper reports come
from.


Your arithmetic is OK, but there's more to latency than the size of the
sample buffer. I don't know exactly how Reaper works internally, but at
some point it measures the actual delay between input and output so that
it can properly compensate for that delay (by automatically
re-positioning the just-recorded track) when you're doing a punch-in or
overdub. The un-accounted-for time has to do with how long it takes the
computer to pass the data through the driver.


--
"Today's production equipment is IT based and cannot be operated without
a passing knowledge of computing, although it seems that it can be
operated without a passing knowledge of audio" - John Watkinson

Drop by http://mikeriversaudio.wordpress.com now and then
  #9   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.

On 12/10/2014 08:50 PM, hank alrich wrote:
PStamler wrote:

Some of the latency may come from causes other than buffering. The
computer may spend a little time crunching the numbers too.

Peace, Paul


Are there any plugins involved, any processing?


No, it was actually just a blank project with no tracks.


  #10   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.

On 12/11/2014 03:37 AM, William Sommerwerck wrote:
How many channels are you recording? If you have only one CPU, you can buffer only one channel at any instant. For two channels and 96k sampling rate, that would be 2.7ms total.

QED?


It's a Quad core machine, but I don't think I agree with you about the buffers.
It wouldn't make sense that the latency would be proportional to the channel count.





  #11   Report Post  
Posted to rec.audio.pro
William Sommerwerck William Sommerwerck is offline
external usenet poster
 
Posts: 4,718
Default A little brain dead right now, so I need math help.

"Tobiah" wrote in message ...
On 12/11/2014 03:37 AM, William Sommerwerck wrote:

How many channels are you recording? If you have only one CPU,
you can buffer only one channel at any instant. For two channels
and 96k sampling rate, that would be 2.7ms total.
QED?


It's a quad core machine, but I don't think I agree with you about the
buffers. It wouldn't make sense that the latency would be proportional
to the channel count.


Why not? A processor can only perform one operation at a time. Wouldn't it
take 16 times as long to buffer 32 channels as it would to buffer two?

Of course, in a 64-bit OS, you should be able to buffer four 16-bit samples at
the same time. But I think I'm basically correct about this.

Have you asked the company who wrote the software?




  #12   Report Post  
Posted to rec.audio.pro
[email protected] makolber@yahoo.com is offline
external usenet poster
 
Posts: 614
Default A little brain dead right now, so I need math help.



Why not? A processor can only perform one operation at a time. Wouldn't it
take 16 times as long to buffer 32 channels as it would to buffer two?


yes 16 channels may take 16 times longer than 1 channel , BUT as long as that the time to move the samples for all N channels is less than 1/44.1 kHz then the machine can move all those samples (and more) in the alloted time. It will usually have time left over to idle around and take a break.

The machine does a lot more than just move samples around so it better be able to get it all done. Of course, if you add more and more channels and more and more processing and other tasks to the point where it can't get it all done in 1 / 44.1 kHz, then yes you start to get drop outs etc.


Mark

  #13   Report Post  
Posted to rec.audio.pro
William Sommerwerck William Sommerwerck is offline
external usenet poster
 
Posts: 4,718
Default A little brain dead right now, so I need math help.

wrote in message ...

BUT as long as that the time to move the samples for all
N channels is less than 1/44.1 kHz [in this case, 1/96kHz]...


...then the machine can move all those samples (and more) in the
allotted time. It will usually have time left over to idle around and
take a break.


And a sip of Mom's Robot Oil.

What, then, are the mathematical and practical meanings of "latency"?

  #14   Report Post  
Posted to rec.audio.pro
Mike Rivers[_2_] Mike Rivers[_2_] is offline
external usenet poster
 
Posts: 2,190
Default A little brain dead right now, so I need math help.

On 12/12/2014 9:18 AM, William Sommerwerck wrote:
What, then, are the mathematical and practical meanings of "latency"?


I wrote a full article about that. It's on my web site, and was in an
older issue of Recording Magazine.

Short answers:
1. If your program reports just plain latency, it's a number you'll
never achieve in practice

2. If the program reports input and output latency separately, that's a
clue that they understand what they're talking about - but still your
actual practical latency will be greater than the sum.

3. The only latency that really matters is the delay between mic/line
input and monitor output. It only matters where it matters, and that's
when you're recording and you're forced, due to a lack of proper studio
hardware, to monitor the source through the computer. This is where
people disagree as to how much is too much, or how little is
satisfactory. It's one of those "it depends" things.

4. When it comes to punch-ins, any civilized DAW these days will know
the input and output delays and put the newly recorded audio in the
right place on the time line. Same goes for when you're mixing with
plug-ins which add delay of their own.

5. It's easy to measure input to output delay, and then you'll know what
it really is. Play around with settings and you can see how much a
change in buffer size affects the delay between line/mic input and
monitor output.



--
"Today's production equipment is IT based and cannot be operated without
a passing knowledge of computing, although it seems that it can be
operated without a passing knowledge of audio" - John Watkinson

Drop by http://mikeriversaudio.wordpress.com now and then
  #15   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.

On 12/12/2014 06:18 AM, William Sommerwerck wrote:
wrote in message ...

BUT as long as that the time to move the samples for all
N channels is less than 1/44.1 kHz [in this case, 1/96kHz]...


Right. One may assert that a single core CPU can only do
one thing at once, but it can do a jillion things in a jiffy.
The buffer is essentially there for when the CPU gets sidetracked
servicing another piece of hardware or something. If the buffer
is large enough, the soundcard will be able to feed itself for
a bit until the CPU gets around to pumping samples again.

As far as I can tell, this buffer size is the largest contributor
to I/O latency. But it's a prescriptive setting. I specify how
much latency I think I can live with, and if all goes well, the
CPU will never be out to lunch when the buffer approaches empty.

Adding tracks to the mix does not change the timing of anything.
It simply makes the CPU work harder in order to make the deadline
of being around when the buffers approach empty. If my CPU is fast
enough, many tracks can be handled at once with the same buffer-size/latency
(again disregarding other causes of latency). At some point,
the CPU will not be able to handle any more tracks with any buffer size
when the absolute sample pushing capability has been exceeded.
Then, rather than latency increasing, somehow magically distorting
time and giving the CPU more time to do it's job, the stream fails
and we get breaks in the audio.

All to say that increasing channels or tracks does not increase
latency. It only increases your chance of overloading your CPU.





...then the machine can move all those samples (and more) in the
allotted time. It will usually have time left over to idle around and
take a break.


And a sip of Mom's Robot Oil.

What, then, are the mathematical and practical meanings of "latency"?




  #16   Report Post  
Posted to rec.audio.pro
William Sommerwerck William Sommerwerck is offline
external usenet poster
 
Posts: 4,718
Default A little brain dead right now, so I need math help.

"Tobiah" wrote in message ...

clear explanation snipped

Now I (think I) understand. Latency is a worst-case situation, the maximum
amount of I/O delay the user will tolerate. It is not a measure of how long it
takes to "move things around" under non-stressful conditions.

  #17   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.

On 12/12/2014 08:37 AM, William Sommerwerck wrote:
"Tobiah" wrote in message ...

clear explanation snipped

Now I (think I) understand. Latency is a worst-case situation, the
maximum amount of I/O delay the user will tolerate. It is not a
measure of how long it takes to "move things around" under
non-stressful conditions.


Not worst case; the latency is going to be constant given a particular
buffer setting. If I set it so that latency is 10ms, I will
never get a faster round trip than that. Normally every sample
will take exactly that long to make if from input to output.

We want that number to be smaller, and the CPU doesn't have
to work any harder (well a tiny bit) when the latency is low.
It just means that it might get caught doing something else
for a piece of hardware of software that thinks that *it's*
cpu attention is absolutely necessary when that short buffer
comes to and end.

All that is aside from how many effects or channels we use,
really. As long as there is enough CPU to process everything
at the current sample rate, everything works. If there is not,
then a larger buffer/ more latency will only put off the inevitable,
and we will eventually hear a break in the sound.

  #18   Report Post  
Posted to rec.audio.pro
Les Cargill[_4_] Les Cargill[_4_] is offline
external usenet poster
 
Posts: 1,383
Default A little brain dead right now, so I need math help.

William Sommerwerck wrote:
"Tobiah" wrote in message ...
On 12/11/2014 03:37 AM, William Sommerwerck wrote:

How many channels are you recording? If you have only one CPU,
you can buffer only one channel at any instant. For two channels
and 96k sampling rate, that would be 2.7ms total.
QED?


It's a quad core machine, but I don't think I agree with you about the
buffers. It wouldn't make sense that the latency would be proportional
to the channel count.


Why not? A processor can only perform one operation at a time. Wouldn't
it take 16 times as long to buffer 32 channels as it would to buffer two?


You're not compute bound, so no. It'll take 16 times as long somewhere
but that will be small potatoes in the larger scheme of things.

Of course, in a 64-bit OS, you should be able to buffer four 16-bit
samples at the same time. But I think I'm basically correct about this.


They'll be blocked into one chunk over USB or Firewire depending on how
you configure the buffering. Mo' samples, mo chunk.

Have you asked the company who wrote the software?


HA!

--
Les Cargill

  #19   Report Post  
Posted to rec.audio.pro
Les Cargill[_4_] Les Cargill[_4_] is offline
external usenet poster
 
Posts: 1,383
Default A little brain dead right now, so I need math help.

William Sommerwerck wrote:
wrote in message
...

BUT as long as that the time to move the samples for all
N channels is less than 1/44.1 kHz [in this case, 1/96kHz]...


...then the machine can move all those samples (and more) in the
allotted time. It will usually have time left over to idle around and
take a break.


And a sip of Mom's Robot Oil.


Mmmm. Mom's.

What, then, are the mathematical and practical meanings of "latency"?


So the machinery on the end of the wire has to assemble samples.
It puts them samples in "boxes" of varying size before they go to the
"loading dock" to be transmitted via , say USB , to the host computer,
which unpacks 'em and stores them, or sends them *back* out USB to the
output side.

--
Les Cargill
  #20   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.

Of course, in a 64-bit OS, you should be able to buffer four 16-bit
samples at the same time. But I think I'm basically correct about this.


It's worth pointing out that a 64-bit CPU/OS does not equate to double
the throughput in most operations compared to 32-bit. Depending on how
efficient the programmer/compiler, there will be an advantage, but when
you talk about shoving samples around, you generally can't just assume
that four 16 bit samples will now fit where two used to. The CPU still
marches to the clock cycle conductor, and when handling discreet values
like samples, particularly when we only really need 32-bit ones, is
going to be only marginally faster on a 64-bit machine.

Otherwise it would be like saying that we could improve amazon.com's
throughput if only they would use larger boxes for everything. Nope,
because of the logic necessary to properly deliver the
payload, larger boxes would do very little.

This is all very rough, and the last time I programmed to the metal was
on a Z80, so take it with a grain of salt. Another way of what I'm
saying, is that for most applications, a 64 bit anything is going to
be only marginally faster than a 32 bit of the same thing. The clock
speed is what really moves things along.



  #21   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.

On 12/10/2014 7:15 PM, PStamler wrote:
Some of the latency may come from causes other than buffering. The
computer may spend a little time crunching the numbers too.

Peace, Paul


Yes, I hadn't thought about that much, although Mike made this point
abundantly clear. I suppose there are basically buffers everywhere
(visualizing Buzz Lightyear). Even devices that claim 'direct
monitoring' use the phrase 'Near zero latency' or similar perhaps
because they normally still do a AD/DA stage which is certainly not
zero latency, or because they account for the speed of the electrons
down the wire, but that would be absurd.
  #22   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.


It's a quad core machine, but I don't think I agree with you about the
buffers. It wouldn't make sense that the latency would be proportional
to the channel count.


Why not? A processor can only perform one operation at a time. Wouldn't
it take 16 times as long to buffer 32 channels as it would to buffer two?


You're not compute bound, so no. It'll take 16 times as long somewhere
but that will be small potatoes in the larger scheme of things.


This.


  #23   Report Post  
Posted to rec.audio.pro
Mike Rivers[_2_] Mike Rivers[_2_] is offline
external usenet poster
 
Posts: 2,190
Default A little brain dead right now, so I need math help.

On 12/12/2014 9:13 PM, Tobiah wrote:
I suppose there are basically buffers everywhere
(visualizing Buzz Lightyear). Even devices that claim 'direct
monitoring' use the phrase 'Near zero latency' or similar perhaps
because they normally still do a AD/DA stage which is certainly not
zero latency, or because they account for the speed of the electrons
down the wire, but that would be absurd.


Buffers actually have a purpose other than to cause annoying delays.
They store data coming in from the driver until the processor is ready
to use it, and provide a place for it to relax if the driver spits out
data before it's ready to be used. If the buffers are too small, you
lose data. If they're larger than it needs to be, you have more delay in
the system than you need. But you do need some delay since data flow
isn't continuous.

Delay due to A/D and D/A conversion is sometimes buffered, sometimes
not. Converters from 10-15 years ago usually had a round trip time of
1.5 to 3 milliseconds. The ones in common use today cut that by a factor
of 10 to 20, so "near zero latency" can indeed be pretty close to zero
for an interface that has a DSP mixer for monitoring and the input
source audio doesn't need to make a trip through the computer in order
to get to the monitor output.

If your interface connects to the computer via USB, which operates in
its own fits and starts, the driver usually includes a buffer right at
the USB port in addition to the buffers between the driver and the DAW
program. It took them a while to figure that out, so it's a fairly
recent addition and not every device includes, or needs it. If it's
included, the USB port buffer is usually engaged by default when the
driver is installed, and it's usually pretty generous. This is so the
manufacturer doesn't get flooded with tech support calls about
stuttering and dropouts when the interface is first installed. It takes
a novice user a while to discover that there's too much latency, and
then when he goes on line to see what to do about it, he gets the advice
to make the buffers smaller, but he doesn't know about the USB buffer.
Pssssst . . . It's still a bit of a secret.

--
"Today's production equipment is IT based and cannot be operated without
a passing knowledge of computing, although it seems that it can be
operated without a passing knowledge of audio" - John Watkinson

Drop by http://mikeriversaudio.wordpress.com now and then
  #24   Report Post  
Posted to rec.audio.pro
William Sommerwerck William Sommerwerck is offline
external usenet poster
 
Posts: 4,718
Default A little brain dead right now, so I need math help.

I wish I'd never said anything.
  #25   Report Post  
Posted to rec.audio.pro
hank alrich hank alrich is offline
external usenet poster
 
Posts: 4,736
Default A little brain dead right now, so I need math help.

William Sommerwerck wrote:

I wish I'd never said anything.


Tough cookie, kiddo, and thanks for speaking up. Seriously. Great
blather derived from that, and now I feel all latent.

;-)

--
shut up and play your guitar * HankAlrich.Com
HankandShaidriMusic.Com
YouTube.Com/WalkinayMusic


  #26   Report Post  
Posted to rec.audio.pro
William Sommerwerck William Sommerwerck is offline
external usenet poster
 
Posts: 4,718
Default A little brain dead right now, so I need math help.

"hank alrich" wrote in message ...
William Sommerwerck wrote:

I wish I'd never said anything.


Tough cookie, kiddo, and thanks for speaking up. Seriously.
Great blather derived from that, and now I feel all latent.


I just checked the OED, and can't find any definition of "latent" that seems
to fit the content. "Latent learning" (learning that has taken place without
conscious purpose and that is not manifested until there is a goal to be
achieved) seemed closest.

  #27   Report Post  
Posted to rec.audio.pro
Mike Rivers[_2_] Mike Rivers[_2_] is offline
external usenet poster
 
Posts: 2,190
Default A little brain dead right now, so I need math help.

On 12/14/2014 6:44 AM, William Sommerwerck wrote:
I just checked the OED, and can't find any definition of "latent" that
seems to fit the content. "Latent learning" (learning that has taken
place without conscious purpose and that is not manifested until there
is a goal to be achieved) seemed closest.


We have a lot of dumb terms in this business. Latency is one. If you
have something to advertise or complain about, you make up or adopt a
term for it.

I can sort of see "latency" in this context, as it's something that has
happened that you don't see the effect of immediately, but after some
time (a couple of milliseconds) it comes around to bite you.

--
"Today's production equipment is IT based and cannot be operated without
a passing knowledge of computing, although it seems that it can be
operated without a passing knowledge of audio" - John Watkinson

Drop by http://mikeriversaudio.wordpress.com now and then
  #28   Report Post  
Posted to rec.audio.pro
Les Cargill[_4_] Les Cargill[_4_] is offline
external usenet poster
 
Posts: 1,383
Default A little brain dead right now, so I need math help.

William Sommerwerck wrote:
"hank alrich" wrote in message
...
William Sommerwerck wrote:

I wish I'd never said anything.


Tough cookie, kiddo, and thanks for speaking up. Seriously.
Great blather derived from that, and now I feel all latent.


I just checked the OED, and can't find any definition of "latent" that
seems to fit the content. "Latent learning" (learning that has taken
place without conscious purpose and that is not manifested until there
is a goal to be achieved) seemed closest.



Physics has used the term "latent heat".

--
Les Cargill
  #29   Report Post  
Posted to rec.audio.pro
Tobiah Tobiah is offline
external usenet poster
 
Posts: 666
Default A little brain dead right now, so I need math help.

On 12/14/2014 3:44 AM, William Sommerwerck wrote:
"hank alrich" wrote in message
...
William Sommerwerck wrote:

I wish I'd never said anything.


Tough cookie, kiddo, and thanks for speaking up. Seriously.
Great blather derived from that, and now I feel all latent.


I just checked the OED, and can't find any definition of "latent" that
seems to fit the content. "Latent learning" (learning that has taken
place without conscious purpose and that is not manifested until there
is a goal to be achieved) seemed closest.


I found:

the delay between the receipt of a stimulus by a sensory nerve and the
response to it.
Reply
Thread Tools
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Grateful Dead Engineer Owsley Stanley Dead at 76 david correia Pro Audio 19 March 23rd 11 03:33 AM
Do the math!!! 44.1 to 48k ted hyland Pro Audio 56 November 4th 05 12:40 PM
Is Locksmithing as dead as Linux? Or is it as dead as recording studios? Aegis Pro Audio 3 May 30th 04 02:22 AM
Is Locksmithing as dead as Linux? Or is it as dead as recording studios? Aegis Pro Audio 0 May 30th 04 02:18 AM
Is Locksmithing as dead as Linux? Or is it as dead as recording studios? Aegis Pro Audio 0 May 30th 04 02:18 AM


All times are GMT +1. The time now is 09:10 PM.

Powered by: vBulletin
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright 2004-2024 AudioBanter.com.
The comments are property of their posters.
 

About Us

"It's about Audio and hi-fi"