audio-talk

steve s wrote: ↑

Fri Sep 25, 2020 7:35 pm

Nick wrote: ↑

Fri Sep 25, 2020 3:18 pm

Wasn't your Laverda orange?

Still got that nick, the 1st 1200's where blue or red, mines a blue one. I could do to get it back on the road as it now tax and mot free

Ok, It was the Jota that was orange if I remember?

Wasn't your Laverda orange?

I was nowhere close to that. Nearest I got, was sending JPEG frames captured and compressed by a Cyrus chip (I think) and then stored onto a hard disk, and then streamed via ISDN to a remote station for security use. It would capture the frames around alarm activation, call up the monitoring station...

Oh, and while there is a non zero chance that a error could creep in past the multiple check sums. The chances of it resulting in a continuous small change in the sound that comes out of the DAC instead of a click or burst of noise is zero. I can see network problems causing more or less jitter on t...

Not sure it was ever relevant as the top layer (If I remember involved Corba). Ok, that's a bit harsh.IP was what happened and while you can push that into the OSI model, its not as segregated (and RFC 3439 explains why). What do the kids use now-a-days? Magic pigeon transport wrapped around by a li...

above layer four

Ahh, the old OSI model, kids today will wonder what you are talking about

It may be the case that something in the system was running out of processing power/time, depends on what encoding/decoding was going on. Or it could have just been a bug?

I use eagle. Its all down to the availability and accuracy of part libraries.

at motorway services each car parking space would need to be a charging point

Yep, that would work. No reason why not. Likewise most other car parks.

That doesn't match my (and my colleagues) experience with video and audio links between IP endpoints where we have route associated errors in the encoded video and/or audio data streams but the TCP/IP or UDP layer isn't showing associated errors. The clearest case I have of this was an IP route bet...

If its got optical in (which it seems to have) then yep, that would do it.

Yep, and I suggested the first thing to try was to see if we could convert the data stream from the sb and the transport back into a WAV file to see if there was any difference there.

Yep, but on top of the wifi stack will be a TCP/IP (or UDP) endpoint, so you should (will) get error free transmission or no data. The world as we know it would stop if there was errors in what comes out of a socket interface. Really just trying to think through what might cause the sort of bit-stre...

I would have thought the chances of both the front and rear disk's wearing out at the same time was low.

The dac as far as i can tell should be seeing the essentially the same data stream up its optical input, the cd transport sending the original data from the cd and the sb sending a copy of that data. I just swapped the optical cable from the sb to the transport so there shouldnt be any appreciable ...

Sure thing and I would look carefully at the wifi signal and associated spectrum - I wouldn't be surprised if there is another router in the vicinity on the same or adjacent channel...

What are you thinking that would do?