Close

Page 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 61
  1. #51

    Default Re: SAC SYSTEM BUILD QUESTIONS

    Quote Originally Posted by cgrafx View Post
    But then how do you decide when the channel is actually off or the source is just not playing anything?
    Well, I would have thought that the converter itself would send a message to the software that said: "This circuit is now closed" or "This circuit is now open". If you plugged a mic in, it would complete the circuit and if you unplugged it - it would render it open. The converter could notice that and report it. Not high tech, particularly, but useful. I presume the converter is sending events - one type could indicate "plugged in".

    I'm sure the reality is more complex than that. Maybe there's a standard that was itself the extension of an older standard some hardware still uses that wouldn't have required it and might crash if an event type was added. Or... you know: something. I've added bags on the side of enough tired old war horses to know that you rarely get what seems obvious to expect to work with.

  2. #52
    Join Date
    Jul 2006
    Location
    SF Bay Area
    Posts
    1,509

    Default Re: SAC SYSTEM BUILD QUESTIONS

    Quote Originally Posted by John Ludlow View Post
    Well, I would have thought that the converter itself would send a message to the software that said: "This circuit is now closed" or "This circuit is now open". If you plugged a mic in, it would complete the circuit and if you unplugged it - it would render it open. The converter could notice that and report it. Not high tech, particularly, but useful. I presume the converter is sending events - one type could indicate "plugged in".

    I'm sure the reality is more complex than that. Maybe there's a standard that was itself the extension of an older standard some hardware still uses that wouldn't have required it and might crash if an event type was added. Or... you know: something. I've added bags on the side of enough tired old war horses to know that you rarely get what seems obvious to expect to work with.
    No, events. That isn't a thing. Audio data is just a stream of data. A mic input doesn't have any physical switches attached to it. I doesn't know that a connection has been made or not. The closest thing to a switched circuit would be a TRS connector that can have switched inputs (Normally open, or Normally closed), but would almost always be used for signal routing, not circuit signaling.

    Again, how would the system determine if there is supposed to be a signal there or not?

    Inputs don't only have microphones attached to them. An input could be a keyboard or an iPad that wouldn't be making any sound until a key is pressed or the play button is pushed.

    Microphones can also have mute switches on them.

    In the rare instances when hardware has tried to be smart, its actually caused problems, because there is a delay in turning back on.

    There was a rev of the Behringer ADA's that did that and it was problematic. Keep in mind though that was for output D/A signals only. There just isn't effective way to do that in the input side of a system, because any analog input will always have some noise on it and will never produce a 000000 data stream.

    The other thing to consider is silence is not an invalid data state, nor is it one that you can make any hard-line specific assumptions about.
    Last edited by cgrafx; 07-13-2019 at 02:13 PM.
    ---------------------------------------
    Philip G.

  3. #53

    Default Re: SAC SYSTEM BUILD QUESTIONS

    Quote Originally Posted by cgrafx View Post
    No, events. That isn't a thing. Audio data is just a stream of data. A mic input doesn't have any physical switches attached to it. I doesn't know that a connection has been made or not. The closest thing to a switched circuit would be a TRS connector that can have switched inputs (Normally open, or Normally closed), but would almost always be used for signal routing, not circuit signaling.

    Again, how would the system determine if there is supposed to be a signal there or not?

    Inputs don't only have microphones attached to them. An input could be a keyboard or an iPad that wouldn't be making any sound until a key is pressed or the play button is pushed.

    Microphones can also have mute switches on them.

    In the rare instances when hardware has tried to be smart, its actually caused problems, because there is a delay in turning back on.

    There was a rev of the Behringer ADA's that did that and it was problematic. Keep in mind though that was for output D/A signals only. There just isn't effective way to do that in the input side of a system, because any analog input will always have some noise on it and will never produce a 000000 data stream.

    The other thing to consider is silence is not an invalid data state, nor is it one that you can make any hard-line specific assumptions about.
    Oh - I didn't realize that's the way the data stream is structured. That's too bad.

    When you plug a mic in - it completes the circuit and at least some electricity passes through it on the analog side - which can be detected. Unless, as you pointed out, the switch on the mic is turned off, in which case the circuit is open. But, if it is open there is no need to monitor it until someone turns it back on.

    The digital data stream is another matter - and that's probably the sticking point. If it is a dumb data stream then everything is considered to be digital audio and there's nothing further that could be done with it. There's that 'old standard' that holds it back. Doing it as events (the way midi, for instance, is done) would be smarter, in my opinion, because information besides data could be transferred within the stream. It would also be tougher to do because there's an awful lot of audio samples within a single second compared to, again for instance, MIDI. And the stream would have to be larger per event to handle the event baggage. But - look at TCP/IP. That also carries a heavy, potentially frequent, data stream and: it is done in discrete packets in which the packet declares what kind of data it represents. So - it's a choice, not a requirement of the limits of technology. The way it's done now is leaner on the transport side - but it requires much more processing on the application side to accommodate it.

    And, as far as a perceived delay - I don't know the specific instance you mention, but that was surely in the implementation. The on or off event need only be 1 sample/packet-length long and it could be automatically removed from the stream before buffering.

    All that is moot though. The increase in hardware sophistication that would be required to handle events, and the inter-company politics that would be required to change the standard, aren't worth the benefit to the software programmers in knowing that actively looking for music to appear on a channel is pointless. That, plus it ain't broke now and there's an awful lot of existing hardware that would have to be scrapped to make it the new standard. It's not going to happen.

    On the other hand - there's Dante...

  4. #54

    Default Re: SAC SYSTEM BUILD QUESTIONS

    What about LatencyMon, Philip - do you use it or something else to determine dropped samples?

  5. #55
    Join Date
    Jul 2006
    Location
    SF Bay Area
    Posts
    1,509

    Default Re: SAC SYSTEM BUILD QUESTIONS

    Quote Originally Posted by John Ludlow View Post
    What about LatencyMon, Philip - do you use it or something else to determine dropped samples?
    I'm just looking at dropped buffers in SAC or SAW Studio. This is what tells me if the system can process all the requested audio data in the time allocated based on the buffer setting. The lower the buffer setting the less time available to process data.

    Conversely the lower the buffer setting the lower the input to output latency as well. So the goal is to get the buffer setting as low as possible without dropping buffers.

    My current live system running at 48kHz and 1/64 is just a little over 6ms input to output.

    Running at 1/32 lowers the latency about 1.5-2ms, which would get me very close to 4ms input to output.
    ---------------------------------------
    Philip G.

  6. #56
    Join Date
    Jul 2006
    Location
    SF Bay Area
    Posts
    1,509

    Default Re: SAC SYSTEM BUILD QUESTIONS

    Quote Originally Posted by John Ludlow View Post
    Oh - I didn't realize that's the way the data stream is structured. That's too bad.

    When you plug a mic in - it completes the circuit and at least some electricity passes through it on the analog side - which can be detected. Unless, as you pointed out, the switch on the mic is turned off, in which case the circuit is open. But, if it is open there is no need to monitor it until someone turns it back on.

    The digital data stream is another matter - and that's probably the sticking point. If it is a dumb data stream then everything is considered to be digital audio and there's nothing further that could be done with it. There's that 'old standard' that holds it back. Doing it as events (the way midi, for instance, is done) would be smarter, in my opinion, because information besides data could be transferred within the stream. It would also be tougher to do because there's an awful lot of audio samples within a single second compared to, again for instance, MIDI. And the stream would have to be larger per event to handle the event baggage. But - look at TCP/IP. That also carries a heavy, potentially frequent, data stream and: it is done in discrete packets in which the packet declares what kind of data it represents. So - it's a choice, not a requirement of the limits of technology. The way it's done now is leaner on the transport side - but it requires much more processing on the application side to accommodate it.

    And, as far as a perceived delay - I don't know the specific instance you mention, but that was surely in the implementation. The on or off event need only be 1 sample/packet-length long and it could be automatically removed from the stream before buffering.

    All that is moot though. The increase in hardware sophistication that would be required to handle events, and the inter-company politics that would be required to change the standard, aren't worth the benefit to the software programmers in knowing that actively looking for music to appear on a channel is pointless. That, plus it ain't broke now and there's an awful lot of existing hardware that would have to be scrapped to make it the new standard. It's not going to happen.

    On the other hand - there's Dante...
    Dante isn't going to change this process, it still has to deliver data in order and on time.

    Digital audio was designed to work as a drop in replacement for analog audio and as such has to live in that continuous non-discrete environment.

    TCP/IP ethernet was specifically designed from the ground up to be a discrete packet-based protocol that can re-transmit errors, and handle both delayed and and out of order packet delivery.

    Real-time low-latency audio can't have any of those things. Data has to happen in order, can't be delayed and can't wait for retransmission of error packets.

    Thats one of the reasons ethernet can be such a difficult transport protocol for low-latency live streaming.

    MIDI by its very nature is nothing but an event protocol. That is in fact all it does, process events. Its only marginally real-time and it doesn't process audio.

    Plugging a microphone into a preamp doesn't complete a circuit in the traditional sense. Its not a light bulb, it is a source of real-time data from a transducer that is responding to changes in air pressure.

    The microphone preamp doesn't stop amplifying its input source because there isn't something plugged in, or is muted. The A/D circuit doesn't care if the signal is circuit noise or overloaded distortion, its job is simply to convert the source analog stream into its digital representation.

    You also can't turn on a disabled data stream faster than the buffer size, which will never be a single sample, because computers process audio as data packets defined by buffer size.

    If your buffer size is 32 samples and you've been force feeding it zeros, you'll need 32 samples worth of time before it can be filled with real data.

    The buffers are filled and emptied on a regular schedule defined by the sample size and frequency. The whole thing only works if everything stays on schedule where the input and output buffers are filled continuously and on schedule. If you miss your allotted slot (sample rate), you introduce distortion into the output stream. Miss a few buffers and you probably won't hear it, miss a lot of buffers and it will sound like crap. Get your timing out of sync and you'll also get strange artifacts.

    You can't just stop some things and add others. For live audio the chain from Analog Input to Analog Output is continuous real-time data with a fixed low-latency offset. Once its in the digital space it can take detours as long as it doesn't deviate from the assigned input/output schedule. If it can get through the reverb detour, or the compressor detour and still get to the output buffer before the train leaves than all is good, otherwise you start dropping buffers. Drop enough buffers and you derail the train.
    ---------------------------------------
    Philip G.

  7. #57

    Default Re: SAC SYSTEM BUILD QUESTIONS

    Hey SAC and Process Lasso users.
    Considering the system I build with the insight from others on this forum.
    ASUS Prime B360 Plus,
    Intel Core i7-9700K Coffee Lake 8-Core 3.6 GHz
    Windows 10 Enterprise LTSC 64 bit
    32 gig ram, 500 gig and 1 T byte M.2 SSD
    2 Samsung 55” TVs as Monitors one for SAC one for Effects


    What might be the best practices for an 8 core setup using the program Process Lasso?
    I have been setting all windows processes to cores 0-3 while setting SAC to 4-5 and the RME HDSP9652 (2ea.) an Totalmix to 6-7.

    System seem to work ok at 2-64 buffers but still drops at times.
    Could this be because I am using two cores for SAC as opposed to 1?
    Would it also help to set Sac to core 4 and in BIOS give priority to that core.

    Are there any other BIOS settings that I can try to give SAC all it can get out of the setup I have? I admit I am not all that great with advanced BIOS settings.

    Thanks in advance

    Warren
    Warren @ The Masters Tracks

  8. #58
    Join Date
    Jul 2006
    Location
    SF Bay Area
    Posts
    1,509

    Default Re: SAC SYSTEM BUILD QUESTIONS

    from the testing I've done so far, Core 0 seems to be the primary core and the one windows will default to most of the time.

    I haven't done any high-core systems so not sure how processes are distributed across multiple cores.

    All of the systems I've built are specifically higher clock rate lower core systems (2-core i3 and i5) cpus.

    I've gotten the best results just moving SAC off of core 0 and not worrying about moving anything else.

    Let everything else run where it wants to.

    Turn off all the process lasso functions except for the processor affinity and priority tools. You really don't want it messing around with anything else.

    Run SAC in real-time priority, you'll need to set that both in SAC and in process Lasso. Windows 10 won't elevate SAC to Real-Time just using the option in SAC.

    Don't run sac as administrator. This helps prevent windows from launching multiple instances of SAC when you double click the app icon.

    I've been able to get 1-32 buffer settings to run with no dropped buffers (although not consistently and only when the screen saver is not allowed to run). I haven't fully identified what specific process dumps all over the audio engine yet, but sometimes it works flawlessly and sometimes it doesn't.

    1-64 has been 100% stable for me.

    There is no advantage to moving the RME drivers to a different core.
    - first, its all very low level code that doesn't consume much in the way of CPU or Memory resources
    - second, every time you switch cores the system has to also do a context switch (which is not conducive to single threaded operations). As long as everything can run in the CACHE RAM for the specific Core all is good, but as soon as data is required from regular RAM the memory buss is locked to the core making the request and none of the other cores can access memory until that request is finished and the buss is released.
    Last edited by cgrafx; 08-29-2019 at 02:22 PM.
    ---------------------------------------
    Philip G.

  9. #59

    Default Re: SAC SYSTEM BUILD QUESTIONS

    Quote Originally Posted by cgrafx View Post
    from the testing I've done so far, Core 0 seems to be the primary core and the one windows will default to most of the time.

    I haven't done any high-core systems so not sure how processes are distributed across multiple cores.

    All of the systems I've built are specifically higher clock rate lower core systems (2-core i3 and i5) cpus.

    I've gotten the best results just moving SAC off of core 0 and not worrying about moving anything else.

    Let everything else run where it wants to.

    Turn off all the process lasso functions except for the processor affinity and priority tools. You really don't want it messing around with anything else.

    Run SAC in real-time priority, you'll need to set that both in SAC and in process Lasso. Windows 10 won't elevate SAC to Real-Time just using the option in SAC.

    Don't run sac as administrator. This helps prevent windows from launching multiple instances of SAC when you double click the app icon.

    I've been able to get 1-32 buffer settings to run with no dropped buffers (although not consistently and only when the screen saver is not allowed to run). I haven't fully identified what specific process dumps all over the audio engine yet, but sometimes it works flawlessly and sometimes it doesn't.

    1-64 has been 100% stable for me.

    There is no advantage to moving the RME drivers to a different core.
    - first, its all very low level code that doesn't consume much in the way of CPU or Memory resources
    - second, every time you switch cores the system has to also do a context switch (which is not conducive to single threaded operations). As long as everything can run in the CACHE RAM for the specific Core all is good, but as soon as data is required from regular RAM the memory buss is locked to the core making the request and none of the other cores can access memory until that request is finished and the buss is released.

    Ok for a test I let windows take control of all cores except 7, HDSP processes are allowed to run on all cores except 7. I sent SAC to 7 and set SAC to Realtime in both SAC and Process Lasso running at 1/32 buffer settings within RME DSP setup and in SAC. System is running at 16 bit and 44.1k. Result was no dropped buffers after 3 hours running 48 inputs, 6 monitors and house, with approx. 6 non native vst plugins and 6 native at 35 CPU (SAC).

    I still want to stress this setup until I can find where its limits are.

    Philip Thanks for all your input, System is getting much more stable as a result.

    Warren
    Warren @ The Masters Tracks

  10. #60

    Default Re: SAC SYSTEM BUILD QUESTIONS

    Having a bit of trouble trying to figure out why my DRAM is running slow, when in bios it is set to DDR4-2666 which it is supposed to be able to do.
    Below info is what the (CPUID ASUS CPU-Z) app says system is doing, if there is any brave souls out there.
    DRAMS are install on slots 2 and 4 as stated is should be in MB manual.

    ASUS Prime B360 Plus MB
    32 G ram

    DIMM # 1
    SMBus address 0x51
    Memory type DDR4
    Module format UDIMM
    Module Manufacturer(ID) Corsair (7F7F9E0000000000000000)
    SDRAM Manufacturer (ID) Micron Technology (2C00000000000000000000)
    Size 16384 MBytes
    Max bandwidth DDR4-2132 (1066 MHz) ??? DDR4-2666 is what they are ???
    Part number CMK32GX4M2A2666C16
    Nominal Voltage 1.20 Volts
    EPP no
    XMP yes
    XMP revision 2.0
    AMP no
    JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
    JEDEC #1 9.0-9-9-22-31 @ 666 MHz
    JEDEC #2 10.0-10-10-25-35 @ 740 MHz
    JEDEC #3 11.0-11-11-27-38 @ 814 MHz
    JEDEC #4 12.0-12-12-30-42 @ 888 MHz
    JEDEC #5 13.0-13-13-32-45 @ 962 MHz
    JEDEC #6 14.0-14-14-35-49 @ 1037 MHz
    JEDEC #7 15.0-15-15-36-50 @ 1066 MHz
    JEDEC #8 16.0-15-15-36-50 @ 1066 MHz
    XMP profile XMP-2666
    Specification DDR4-2666
    Voltage level 1.200 Volts
    Min Cycle time 0.750 ns (1333 MHz)
    Max CL 16.0
    Min tRP 13.49 ns
    Min tRCD 13.49 ns
    Min tRAS 26.11 ns
    Min tRC 39.74 ns
    Min tRRD 3.74 ns
    XMP timings table CL-tRCD-tRP-tRAS-tRC-CR @ frequency (voltage)
    XMP #1 9.0-11-11-20-30-n.a @ 750 MHz (1.200 Volts)
    XMP #2 10.0-12-12-22-34-n.a @ 834 MHz (1.200 Volts)
    XMP #3 11.0-13-13-24-37-n.a @ 917 MHz (1.200 Volts)
    XMP #4 12.0-14-14-27-40-n.a @ 1000 MHz (1.200 Volts)
    XMP #5 13.0-15-15-29-44-n.a @ 1084 MHz (1.200 Volts)
    XMP #6 14.0-16-16-31-47-n.a @ 1167 MHz (1.200 Volts)
    XMP #7 15.0-17-17-33-50-n.a @ 1251 MHz (1.200 Volts)
    XMP #8 16.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)
    XMP #9 17.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)
    XMP #10 18.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)
    XMP #11 19.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)
    XMP #12 20.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)

    DIMM # 2
    SMBus address 0x53
    Memory type DDR4
    Module format UDIMM
    Module Manufacturer(ID) Corsair (7F7F9E0000000000000000)
    SDRAM Manufacturer (ID) Micron Technology (2C00000000000000000000)
    Size 16384 MBytes
    Max bandwidth DDR4-2132 (1066 MHz) ??? DDR4-2666 is what they are ???
    Part number CMK32GX4M2A2666C16
    Nominal Voltage 1.20 Volts
    EPP no
    XMP yes
    XMP revision 2.0
    AMP no
    JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
    JEDEC #1 9.0-9-9-22-31 @ 666 MHz
    JEDEC #2 10.0-10-10-25-35 @ 740 MHz
    JEDEC #3 11.0-11-11-27-38 @ 814 MHz
    JEDEC #4 12.0-12-12-30-42 @ 888 MHz
    JEDEC #5 13.0-13-13-32-45 @ 962 MHz
    JEDEC #6 14.0-14-14-35-49 @ 1037 MHz
    JEDEC #7 15.0-15-15-36-50 @ 1066 MHz
    JEDEC #8 16.0-15-15-36-50 @ 1066 MHz
    XMP profile XMP-2666
    Specification DDR4-2666
    Voltage level 1.200 Volts
    Min Cycle time 0.750 ns (1333 MHz)
    Max CL 16.0
    Min tRP 13.49 ns
    Min tRCD 13.49 ns
    Min tRAS 26.11 ns
    Min tRC 39.74 ns
    Min tRRD 3.74 ns
    XMP timings table CL-tRCD-tRP-tRAS-tRC-CR @ frequency (voltage)
    XMP #1 9.0-11-11-20-30-n.a @ 750 MHz (1.200 Volts)
    XMP #2 10.0-12-12-22-34-n.a @ 834 MHz (1.200 Volts)
    XMP #3 11.0-13-13-24-37-n.a @ 917 MHz (1.200 Volts)
    XMP #4 12.0-14-14-27-40-n.a @ 1000 MHz (1.200 Volts)
    XMP #5 13.0-15-15-29-44-n.a @ 1084 MHz (1.200 Volts)
    XMP #6 14.0-16-16-31-47-n.a @ 1167 MHz (1.200 Volts)
    XMP #7 15.0-17-17-33-50-n.a @ 1251 MHz (1.200 Volts)
    XMP #8 16.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)
    XMP #9 17.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)
    XMP #10 18.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)
    XMP #11 19.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)
    XMP #12 20.0-18-18-35-53-n.a @ 1333 MHz (1.200 Volts)

    DIMM # 1
    SPD registers
    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
    00 23 10 0C 02 85 21 00 08 00 00 00 03 09 03 00 00
    10 00 00 08 0C FC 03 00 00 6C 6C 6C 11 08 74 F0 0A
    20 20 08 00 05 00 B8 1E 2B 2B 00 00 00 00 00 00 00
    30 00 00 00 00 00 00 00 00 00 00 00 00 16 36 16 36
    40 16 36 16 36 00 00 2B 0C 2B 0C 2B 0C 2B 0C 00 00
    50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    70 00 00 00 00 00 ED B5 CF 00 00 00 00 00 C2 7D 54
    80 11 11 01 01 00 00 00 00 00 00 00 00 00 00 00 00
    90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DE 27
    100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    140 02 9E 00 00 00 00 00 00 00 43 4D 4B 33 32 47 58
    150 34 4D 32 41 32 36 36 36 43 31 36 20 20 00 80 2C
    160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    180 0C 4A 01 20 00 00 00 00 00 94 00 00 06 FC 3F 04
    190 00 60 6C 6C 10 D1 3E F0 0A 20 08 00 05 00 A8 1E
    1A0 30 00 00 00 00 00 00 00 00 F6 F6 F6 F6 F6 F6 00
    1B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    Actually there is about 63 pages of data but I didn't want to freak anyone out.
    Thank you for looking
    Warren
    Warren @ The Masters Tracks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •