IPB

Welcome Guest ( Log In | Register )

4 Pages V  « < 2 3 4  
Reply to this topicStart new topic
If the output is digital does the player make any difference to the so
phofman
post Aug 5 2012, 21:03
Post #76





Group: Members
Posts: 331
Joined: 14-February 12
Member No.: 97162



QUOTE (saratoga @ Aug 5 2012, 01:55) *
No, its cheaper just figure out what broken device you have that is blocking inside an ISR (!!!) and throw it out a window.


Actually, it would be a crappy driver to be thrown out. The device itself is innocent smile.gif
Go to the top of the page
+Quote Post
[JAZ]
post Aug 5 2012, 21:40
Post #77





Group: Members
Posts: 1797
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



QUOTE (phofman @ Aug 5 2012, 22:03) *
Actually, it would be a crappy driver to be thrown out. The device itself is innocent smile.gif


That is not always the case smile.gif
Remember the Creative Soundblaster Live! , it had a design that was using the PCI bus in excess and caused problems with some chipsets. ( I've quickly searched for a link about it and found this: http://www.tomshardware.co.uk/forum/37211-...opping-crakling . Guess i could find a better source with a better searching)
Go to the top of the page
+Quote Post
xnor
post Aug 5 2012, 23:39
Post #78





Group: Developer
Posts: 1016
Joined: 29-April 11
From: Austria
Member No.: 90198



QUOTE ([JAZ] @ Aug 5 2012, 22:40) *
That is not always the case smile.gif

Yeah but if you can fix all the glitches by reducing the DPC latency then the sound card is not broken, regardless if somebody is absolutely convinced of that. As absurd as it sounds, DPC latency can be (temporarily) reduced even by just restarting/disabling certain Windows services.

saratoga, you don't know what laptop I have, what sound card I use or anything else yet you're absolutely convinced my hardware is broken. I'm sorry if I offended you but imho it's exactly what I said it is. Same goes for your "throw it out a window" statement.

This post has been edited by xnor: Aug 5 2012, 23:50


--------------------
"we are having an educated and deep technical discussion"-amirm
Go to the top of the page
+Quote Post
Arnold B. Kruege...
post Aug 6 2012, 08:14
Post #79





Group: Members
Posts: 4457
Joined: 29-October 08
From: USA, 48236
Member No.: 61311



QUOTE (xnor @ Aug 4 2012, 19:36) *
QUOTE (Arnold B. Krueger @ Aug 5 2012, 00:43) *
On paper, many look like they should be abundantly fast and never lose a sample. But in the real world, stuff breaks and other tasks interfere.

Like ISRs/DPCs? laugh.gif You don't have to try to teach anything here, just tell me what you mean.


Like ISRs, DPCs, and every data bus, register, and byte of memory inside the PC.

I don't have to diagnose the problems, all I have to know is that the problems still happen.

It is a simple fact that people still have tics and pops in PCs that don't route audio through USB. Therefore it is abundantly clear to anybody with an ounce of brains that you can systematically fix USB all you want, and those kinds of problems will still exist, and there will be tics and pops.

This post has been edited by Arnold B. Krueger: Aug 6 2012, 08:17
Go to the top of the page
+Quote Post
phofman
post Aug 6 2012, 17:43
Post #80





Group: Members
Posts: 331
Joined: 14-February 12
Member No.: 97162



If you raise playback buffer/playback latency, will it cure the pops and clicks? The clicks in most cases are simple late delivery of samples to RAM for the soundcard to read via DMA. If you keep the playback process more ahead of the reading pointer, you get more time headroom for the playback chain.

This post has been edited by phofman: Aug 6 2012, 17:44
Go to the top of the page
+Quote Post
[JAZ]
post Aug 6 2012, 19:00
Post #81





Group: Members
Posts: 1797
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



phofman: Yes and no.

With windows Vista and upwards, microsoft changed the way the audio stack worked inside the OS.
With windows XP, I can almost halt the PC if I run an audio thread at high priority and uses all the cpu (ok, one core), but with Vista, you get audio skips.
They moved the audio stack out of the kernel, and that way it lost part of the "privileges" that it had until then.

When defining the buffer in an application, you're defining the buffers that it gives to the driver. With ASIO (and real drivers, not API emulators like ASIO4All), the same buffers are then sent to the soundcard, but with other APIs, that's not necessarily the case.


Now, don't forget that the meaning of multithreading is, in fact, slice tasks of different threads/programs in time fractions determined by the Operating System, and then run each one sequentially, determined by task priority and other order mechanisms.

And here is where the DPC latency plays a role. Basically, the problem is that once the soundcard driver needs audio, it schedules a callback that will provide this data, and this acts as a queue. (separated from user programs and with higher priority).
The latency of the DPC queue is determined by the different drivers that run, and the code it executes. It is expected that these calls are fast, but when they are not, the scheduled callback might not return in time to avoid audio skips.

(Better explained in http://www.thesycon.de/deu/latency_check.shtml#background )

Go to the top of the page
+Quote Post
phofman
post Aug 6 2012, 20:19
Post #82





Group: Members
Posts: 331
Joined: 14-February 12
Member No.: 97162



QUOTE ([JAZ] @ Aug 6 2012, 20:00) *


When defining the buffer in an application, you're defining the buffers that it gives to the driver. With ASIO (and real drivers, not API emulators like ASIO4All), the same buffers are then sent to the soundcard, but with other APIs, that's not necessarily the case.


I am talking about the direct DMA buffer, not a buffer which gets redefined by the mixing layer.

QUOTE ([JAZ] @ Aug 6 2012, 20:00) *

Now, don't forget that the meaning of multithreading is, in fact, slice tasks of different threads/programs in time fractions determined by the Operating System, and then run each one sequentially, determined by task priority and other order mechanisms.

And here is where the DPC latency plays a role. Basically, the problem is that once the soundcard driver needs audio, it schedules a callback that will provide this data, and this acts as a queue. (separated from user programs and with higher priority).
The latency of the DPC queue is determined by the different drivers that run, and the code it executes. It is expected that these calls are fast, but when they are not, the scheduled callback might not return in time to avoid audio skips.


DPC is in single milliseconds at worst, while soundcards easily handle DMA buffers of hundreds of millisecs, some even seconds. The trick (unless low latency required) is to raise the buffer sufficiently.

QUOTE ([JAZ] @ Aug 6 2012, 20:00) *


Well, that document does not mention the DMA buffer at all. Raising the buffer fixes any DPC problems (unless a really buggy driver hogs the CPU), provided one does not need to keep latency low for recording/authoring work. That is a situation very different to pure playback scenario.

I am aware of the fact that raising the buffer is often not an option on windows. That is why I use linux for audio. But the hardware itself is OK, fault of the rigid software stack. I have not heard of the SB Live problem in linux - every PCI card communicates over PCI constantly, reading the sound samples via DMA. IMO the cause is a too low DMA buffer chosen by the proprietary driver, causing underruns for slower PCI hardware.

This post has been edited by phofman: Aug 6 2012, 20:20
Go to the top of the page
+Quote Post
[JAZ]
post Aug 6 2012, 22:08
Post #83





Group: Members
Posts: 1797
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



QUOTE (phofman @ Aug 6 2012, 21:19) *
DPC is in single milliseconds at worst, while soundcards easily handle DMA buffers of hundreds of millisecs, some even seconds. The trick (unless low latency required) is to raise the buffer sufficiently.


Tested latency monitor this afternoon:
CODE
REPORTED DPCs
____________________________________________________________________________________________________
_____
Highest DPC routine execution time (Ás):              19488,501337
Driver with highest DPC routine execution time:       ACPI.sys - Controlador ACPI para NT, Microsoft Corporation

Highest reported total DPC routine time (%):          2,344699
Driver with highest DPC total execution time:         ACPI.sys - Controlador ACPI para NT, Microsoft Corporation

Total time spent in DPCs (%)                          3,438667

DPC count (execution time <250 Ás):                   381482
DPC count (execution time 250-500 Ás):                0
DPC count (execution time 500-999 Ás):                1334
DPC count (execution time 1000-1999 Ás):              6675
DPC count (execution time 2000-3999 Ás):              887
DPC count (execution time >=4000 Ás):                 0


Yes, that says the maximum has been 19 milliseconds. Just playing a song with directsound set at 5 buffers of 1576 samples (176ms of audio latency, 44Khz).
And obviously, i had audio skips.

I can get as low as 59ms with directsound and 25ms with WASAPI (And even less with ASIO and Asio4all). It really depends if the system wants to lag or not.

I was going to ask why you talk about DMA buffers, but I guess this sentence of yours is the key "I am aware of the fact that raising the buffer is often not an option on windows. That is why I use linux for audio."

So, now that we're on linux... What problems have you experienced with USB Audio over it? It's just so that we can conclude that Windows is more prone to the problem, and as such, it's audio stack, and not the USB protocol.
Go to the top of the page
+Quote Post
Roseval
post Aug 6 2012, 22:43
Post #84





Group: Members
Posts: 496
Joined: 26-March 08
Member No.: 52303



Maybe this link is of use: http://www.rme-audio.de/en_products_firefa...s/en_uc_general


--------------------
TheWellTemperedComputer.com
Go to the top of the page
+Quote Post
phofman
post Aug 7 2012, 11:46
Post #85





Group: Members
Posts: 331
Joined: 14-February 12
Member No.: 97162



QUOTE
Yes, that says the maximum has been 19 milliseconds.


Well, I do not know what that number means, since the output also says:

CODE
DPC count (execution time >=4000 Ás):                 0


It could as well be a total time spent in DPCs of ACPI.sys during the test period. No source code available to find out, but you can try to ask the developer.

QUOTE
Just playing a song with directsound set at 5 buffers of 1576 samples (176ms of audio latency, 44Khz).
And obviously, i had audio skips.


I do not know if these are DMA buffers the soundcard is using, or some intermediate buffer for the windows audio subsystem which allocates a different size buffer for the actual transfer to the soundcard. My knowledge of windows audio is almost zero smile.gif

QUOTE
I can get as low as 59ms with directsound and 25ms with WASAPI (And even less with ASIO and Asio4all). It really depends if the system wants to lag or not.


For pure playback the figures do not have to be so low. E.g. MPD uses 500 ms buffer by default.

QUOTE
I was going to ask why you talk about DMA buffers...


Because that is the buffer which counts when dealing with audio nondelivery to the soundcard. For PCI/e devices (not USB) the ASIO buffer is the direct DMA buffer, buffer allocated by linux alsa for raw hw:X device (e.g. used by MPD playing to hw:X device) is the direct DMA buffer too. This is to show that the DMA buffer is accessible, it does not have to be something hidden deep in the driver layer. I have no idea about other windows sound systems. In fact there are developers of some commercial closed-source audio players (I will not name, it is googleable smile.gif ) who have no idea about the DMA transfer and believe the CPU sends data directly to the soundcard.

USB devices work a bit differently, the audio buffer is used by the USB driver to prepare/mix final USB frames for all current USB streams to the actual DMA buffer for the USB controller to read.


QUOTE
So, now that we're on linux... What problems have you experienced with USB Audio over it? It's just so that we can conclude that Windows is more prone to the problem, and as such, it's audio stack, and not the USB protocol.


In the end every OS communicates with the hardware in basically the same manner, unless one features a bug in the driver. Linux offers access to even the lowest software layers which means an advanced user can tweak the params at will. I have tried to torture the USB audio stack and it proved to be surprisingly resilient - http://www.diyaudio.com/forums/pc-based/93...tml#post1719044

Go to the top of the page
+Quote Post

4 Pages V  « < 2 3 4
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th December 2014 - 02:46