| === jta_ is now known as jta | ||
| === Lump|AFK is now known as LumpOfCoal | ||
| holstein | zequence: im not an electornics expert | 22:00 |
|---|---|---|
| holstein | so we dont have to talke about taht in the main channel | 22:00 |
| holstein | zequence: i dont care | 22:00 |
| holstein | im just saying, i ge more noise at lower latency | 22:00 |
| holstein | why? im assuming something is doing more at lower latency | 22:00 |
| holstein | is it power? | 22:01 |
| holstein | i dont know/care | 22:01 |
| holstein | hypothesise away, but i assue you im not tyring to be "correct" | 22:01 |
| holstein | im just stating what i have seen | 22:01 |
| zequence | I'm not making any claims that are "hypothetical" | 22:01 |
| zequence | Just narrowing down what could and what could not be the cause | 22:02 |
| holstein | sure | 22:02 |
| zequence | I'm only interested in solving the problem | 22:02 |
| zequence | I've sometimes experienced that a screen can cause noise to audio devices. The whiter the color, the more noise | 22:04 |
| zequence | And it has happened that a hard drives activity has leaked into the audio signal as well | 22:04 |
| zequence | In both cases I would think it's some sort of ground problem | 22:05 |
| holstein | yup | 22:05 |
| holstein | i would hypothesise a power issue there as well | 22:05 |
| zequence | If the CPU activity is audible, then it kind of sounds like the same thing. I was jusr surprised that low latency would be that audible, as it's not really that much more CPU intensive. If it is a ground problem in this case, it would make sense that anything CPU intensive, at any latency would give noise | 22:07 |
| zequence | Just that there might be more noise at lower latencies when the PC is idle | 22:07 |
| holstein | i dont think its cpu activity | 22:08 |
| holstein | its a constant noise | 22:08 |
| holstein | you start jack at that latency, and its pretty steady | 22:08 |
| holstein | i high pitch whine | 22:08 |
| holstein | its odd | 22:08 |
| holstein | i solved it much the same way though.. by looking into grounding | 22:09 |
| len-1304 | holstein, The PS for the FW unit may be a switcher. | 22:09 |
| zequence | holstein: You said that the noise increased in volume at lower latencies. Does the pitch change too? | 22:09 |
| holstein | zequence: i dont remeber that.. but i dont think so | 22:10 |
| holstein | i think it ws the same pitch and louder | 22:10 |
| len-1304 | Sounds like the power supply | 22:11 |
| len-1304 | Small switching power supplies have gotten cheaper... I see them even in wall warts | 22:11 |
| zequence | It's just that I don't see how the latency would affect the FW power supply | 22:12 |
| holstein | if it causes the device to pull more power | 22:12 |
| holstein | *if* | 22:12 |
| len-1304 | If it is an old unit, I would think the caps are drying out. | 22:12 |
| zequence | But, how would it do that? It's a constant stream of data, no matter which latency | 22:12 |
| len-1304 | The FW unit fills a buffer and sends it every so often, low latency means the cpu in the FW unit has to deal with that part of things more often | 22:13 |
| zequence | len-1304: Isn't that done in the CPU? | 22:14 |
| zequence | the buffering, I mean | 22:14 |
| holstein | zequence: i think you are assuming a constant stream of data.. maybe its not constant? | 22:15 |
| holstein | in not sure | 22:15 |
| zequence | It is a constant stream, but it's also buffered | 22:15 |
| zequence | lower latencies means smaller buffer sizes | 22:16 |
| zequence | I'm just assuming the buffering is done in the CPU, and not in the audio device. | 22:17 |
| === LumpOfCoal is now known as Lump|AFK | ||
| zequence | AFAIK, an audio device sends and receives one sample at a time, following the clock | 22:24 |
| holstein | i wish i knew more about it | 22:24 |
| zequence | If you increase samplerate, the rate at which samples are sent/received increases | 22:25 |
| len-1304 | zequence, (just had lunch) the FW unit also buffers (as does the ice1712) and sends a bufferfull of data at a time. The driver tells the IF how big the buffers are that it wants. | 22:44 |
| len-1304 | That is why there is a lower limit to buffer size for any IF. | 22:44 |
| zequence | len-1304: How about a higher limit? | 22:46 |
| zequence | While jack has a limit of 4096, OSS can go higher | 22:46 |
| zequence | But perhaps the sound server makes up for it | 22:47 |
| len-1304 | That would be a jack limit then. | 22:47 |
| zequence | I wouldn't expect audio devices to be limitless anyway | 22:47 |
| len-1304 | The bigger the buffer used the more shared memory must be set aside | 22:47 |
| len-1304 | But I have three audio interfaces, the lower limit on each is different (-p128, -p64, and -p32) Jack will not even start if I try to use less... because jack tells alsa to ask the device to set a smaller buffer size than it can and the device refuses (sends an error back) | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!