Dropout detection

[Gale Andrews]

When recording from youtube, the audio does not come from audio card, but from Firefox via Windows Wasapi. Stutter comes when network has lag, or when Windows decides to run background processes (10+ counted so far) at top priority, or when background programs uses the disk at top speed.

See if there is anything here: http://wiki.audacityteam.org/wiki/Manag ... nd_Drivers.

Gale

[anahuj]

See if there is anything here: http://wiki.audacityteam.org/wiki/Manag ... nd_Drivers.

The step 2 need to be extended. I have plan to ask in Waves forums. They have that free ardour-based multitrack recorder.

I have disabled many, but have no idea how to disable the rest, or move their execution time frame to more suitable time. Earlier it was nightmare, e.g., suddenly Tomb Raider game went to fps less than 4. Now the rest background programs (Windows system programs) seem to not cause stutter even the disk light is constantly on. One program goes on if I don't touch mouse/keyboard for minute or two; I need a motorized mouse mover.

I will rerecord album or two and compare the recordings. I hear something, like one buffer of audio missing, but nothing which prevents me from listening the albums.

[steve]

Lets say this way: Digital cameras have a system to detect faulty pixels in the image sensor. The data about faulty pixels is used to clean the photos at earliest phase.

In audio, dropouts may occur in many places. The A/D converter in a USB sound card is close to your analogy of a camera's image sensor. Digital audio data is transferred from the A/D converter to the USB controller. This data transfer is invisible to the computer operating system. Any data that is lost here can only be handled in the USB device iteself (as you said, at the "earliest phase"). Typically lost data here is limited to the last few lsbs and appears at driver level as low level noise (random values in the last few bits of 24-bit samples).

The audio data is then transferred via USB to the host. There are at least two clocks involved here - one in the host and one in the client (in the case of ADAT and SPDIF there may be a third clock, but let's ignore that for now). The host and client clocks are unlikely to run at exactly the same speed, so there are three ways to handle this: a) use the host clock, b) use the client clock c) use both clock and calculate an average number of samples per frame (this transfer is frame based). The third option is usually employed, and the low level hardware driver adjusts the number of samples per frame as required to keep the clocks synchronised. Again, this is invisible to the operating system (but this is where use of a highly accurate Word clock might be employed for ADAT, SPDIF and similar systems).

Ideally the low-level USB stack and the USB-Audio should be tightly integrated without buffering. Unfortunately it's near impossible to do that except in embedded systems because the code execution time is unknown, but this is still at kernel sound component level, so invisible to applications. As you said, error handling has to handled at the earliest possible phase.

There may then be one or more proxy layers between the kernel level components and the application. As an example, the chain could look something like this:
A/D -> USB controller (client) -> USB host -> USB audio transport -> ALSA API -> Pulse Audio -> Portaudio -> Audacity.

Handling of lost data has to be handled as early as possible. Audacity at one end of the chain has no idea what is happening at the other end of the chain, or at many of the links between. Audacity can monitor its own data handling, and can query Portaudio, but beyond that Audacity has no idea what occurs earlier in the chain.

[anahuj]

It is enough if the time of the buffers is recorded in the Audacity audio thread. It will detect the problems when recording youtube videos and the video switch when playing a youtube playlist. Fixes two problems I have.

[cyrano]

Which brings us back to avoiding the problem in the first place, by downloading the files from youtube in stead of recording them...

[anahuj]

Which brings us back to avoiding the problem in the first place, by downloading the files from youtube in stead of recording them...

Please don't deviate from the topic: adding a feature to Audacity audio engine, associating the audio stream with the time label stream. Youtube user agreement 5.1(c) forbids me to use a downloader.

I'm staring at the code. Don't yet understand how to add stream of time stamps from audio thread to disk thread (if we record the time data to disk as well).

And I'm worried about this "gAudioIO->mPauseRec". When I play youtube videos, are my recordings stopped at quiet places? Or is this related to "Sound Activated Recording" only? I did read the comments in the code but they are not that clear.

I have written an audio engine, and designed it further before I stopped development because GNU/Linux started to be unfriendly to me, so to speak. Realtime dsp like realtime EQ was part of the design. Moving arbitrary data (like time stamp stream) between audio thread, disk thread, application thread without the audio thread to never stall. It just is sometimes too hard to write to others code because I'm not a qualified software engineer.

[cyrano]

Youtube user agreement 5.1(c) forbids me to use a downloader.

Which is only semantically different from re-recording it...

I'm not against detection of dropouts. But I'm thinking there's no possibility to repair the dropouts. So what use would detection be?

[steve]

Youtube user agreement 5.1(c) forbids me to use a downloader.

I don't think it does. It forbids you to hack their server, but it permits access via their webpage interface, which is what a browser based plug-in is doing.

More relevant is item 5.1(L) (emphasis mine - Terms of service may vary by country, this is from: https://www.youtube.com/static?gl=GB&template=terms)

you agree not to access Content or any reason other than your personal, non-commercial use solely as intended through and permitted by the normal functionality of the Service, and solely for Streaming. "Streaming" means a contemporaneous digital transmission of the material by YouTube via the Internet to a user operated Internet enabled device in such a manner that the data is intended for real-time viewing and not intended to be downloaded (either permanently or temporarily), copied, stored, or redistributed by the user.

which would seem to me (as a layman, not a legal professional). to exclude recording to the same extent as using a video download plug-in. I think Audacity could be placing itself at risk by implementing features that are specifically designed for recording YouTube. We do implement WASAPI loopback recoding, which has a wide variety of uses - basically any job where you need to record the audio output ("loopback") of a device. We also, in many places, warn users that they should check the legality before using it to record streaming Internet content. We are not lawyers, and Audacity is used in many countries where laws vary considerably (particularly concerning copyright and licensing issues). As you have concerns regarding YouTubes terms of service, you should perhaps seek clarification, either from a legal professional or from YouTube themselves.

The more general issue of "detecting dropouts" is far more complex, and I think it goes without saying that Audacity should do what it can to avoid dropouts.