Hi,

The audio player hardware I'm using does indeed have an offset of about
0.2-0.5V when audio is turned on - it does not even have to be playing
anything. This offset is caused by some hardware modifications that are
needed in this layout.

The jamming can consist of all kinds of things. New software builds are
introduced regularly and in some builds errors occur, and in some not.
Most often it has crashed completely, or it is playing some amount of
data over and over again. I do not know that how many samples it is
repeating, and I'd think that the amount varies.

But thank you all, I have had at least something to try at. I think
I'll go with taking parts of the recorded data and compare them to
other parts of that same data.

BR,
vesse

Jon Harris wrote:

   ...

> If the OP is looking at the audio output before the DAC, then it could easily 
> have a non-zero output when it was 'jammed'.  Another common mode of failure for 
> software-based audio devices is what is sometimes called 'buffer looping'.  The 
> idea here is that some higher level sample-fetching software has crashed, but 
> the hardware continues to output the already-fetched audio  in some buffer over 
> and over (like a broken record).  The result is a non-zero but definitely 
> 'jammed' output.  Depending on how long the buffer is, this could be tricky to 
> detect.  (I hear something like this occasionally when listening to the radio, 
> presumably because the audio is being sent digitally over some imperfect 
> transmission media.  When bit errors are detected, it may play back the 
> preceding 'packet' of samples instead of the error-filled ones.  It creates a 
> stuttering effect.) 

Jon,

I addressed those issues in the completed post. I had somehow sent the 
message before finishing it, then deleted it and sent the completed one. 
Your comments are appropriate for the snippet posted first.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

"Jerry Avins" <jya@ieee.org> wrote in message 
news:-6mdnSuyuP-03tTZ4p2dnA@rcn.net...
> vessep@gmail.com wrote:
>> Hi,
>>
>> I have a system that records audio from line in, and stores it as a PCM
>> file. Audio is recorded every once in a while since it would make no
>> sense for me to store it continuosly. What I would need to do is to
>> detect if there's audio coming to line in. I'll try to explain certain
>> situations that I hope that would clarify my needs.
>>
>> The main point is endurance testing, meaning that I just need to know
>> if audio is still playing, say, after 24 hours. This I was hoping to
>> achieve in a way that I record audio like every hour for 30 seconds,
>> and try to detect if it is still playing.
>>
>> Usually the audio is playing, but it could be that player has crashed
>> and only silence with noise is recorded, or the player may have jammed
>> so that it is playing the same sound (sample?) all the time. These must
>> not be approved.
>>
>> I thought that one option would be to somehow measure that there is
>> enough variation in the signal. First I thought that I could check the
>> amplitude somehow, but then noticed that if the sound output is jammed,
>> amplitude could be high even if playback was not working. Silence has a
>> low amplitude (some noise exists), so it could be noticed this way. But
>> how could I detect playback functionality in a more robust way?
>>
>> I'm a C++ programmer, by the way (and have very very little knowledge
>> of DSP).
>
> The whole trick with most tasks is understanding what it is all about. Audio 
> involves /changing/ magnitude, so if the line input is constant, the audio has 
> stopped. You can discriminate silence with noise from a real signal by 
> requiring a small threshold that must be exceeded for the input to be 
> classified as signal.
>
> I can't think of any player that can feed a line input that would not have 
> zero output if it jammed. It's a very unusual audio device whose response 
> extends to DC. What are you using?

If the OP is looking at the audio output before the DAC, then it could easily 
have a non-zero output when it was 'jammed'.  Another common mode of failure for 
software-based audio devices is what is sometimes called 'buffer looping'.  The 
idea here is that some higher level sample-fetching software has crashed, but 
the hardware continues to output the already-fetched audio  in some buffer over 
and over (like a broken record).  The result is a non-zero but definitely 
'jammed' output.  Depending on how long the buffer is, this could be tricky to 
detect.  (I hear something like this occasionally when listening to the radio, 
presumably because the audio is being sent digitally over some imperfect 
transmission media.  When bit errors are detected, it may play back the 
preceding 'packet' of samples instead of the error-filled ones.  It creates a 
stuttering effect.) 

vessep@gmail.com wrote:
> Hi,
> 
> I have a system that records audio from line in, and stores it as a PCM
> file. Audio is recorded every once in a while since it would make no
> sense for me to store it continuosly. What I would need to do is to
> detect if there's audio coming to line in. I'll try to explain certain
> situations that I hope that would clarify my needs.
> 
> The main point is endurance testing, meaning that I just need to know
> if audio is still playing, say, after 24 hours. This I was hoping to
> achieve in a way that I record audio like every hour for 30 seconds,
> and try to detect if it is still playing.
> 
> Usually the audio is playing, but it could be that player has crashed
> and only silence with noise is recorded, or the player may have jammed
> so that it is playing the same sound (sample?) all the time. These must
> not be approved.
> 
> I thought that one option would be to somehow measure that there is
> enough variation in the signal. First I thought that I could check the
> amplitude somehow, but then noticed that if the sound output is jammed,
> amplitude could be high even if playback was not working. Silence has a
> low amplitude (some noise exists), so it could be noticed this way. But
> how could I detect playback functionality in a more robust way?
> 
> I'm a C++ programmer, by the way (and have very very little knowledge
> of DSP).

The whole trick with most tasks is understanding what it is all about. 
Audio involves /changing/ magnitude, so if the line input is constant, 
the audio has stopped. You can discriminate silence with noise from a 
real signal by requiring a small threshold that must be exceeded for the 
input to be classified as signal.

I can't think of any player that can feed a line input that would not 
have zero output if it jammed. It's a very unusual audio device whose 
response extends to DC. What are you using?

Does the jamming consist of repeating a track on a disk? If so, the 
repeat period must be well known, and simply comparing the incoming 
sound with a delayed version should uncover that fault.

Jerry

-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

vessep@gmail.com wrote:
> Hi,
> 
> I have a system that records audio from line in, and stores it as a PCM
> file. Audio is recorded every once in a while since it would make no
> sense for me to store it continuosly. What I would need to do is to
> detect if there's audio coming to line in. I'll try to explain certain
> situations that I hope that would clarify my needs.
> 
> The main point is endurance testing, meaning that I just need to know
> if audio is still playing, say, after 24 hours. This I was hoping to
> achieve in a way that I record audio like every hour for 30 seconds,
> and try to detect if it is still playing.
> 
> Usually the audio is playing, but it could be that player has crashed
> and only silence with noise is recorded, or the player may have jammed
> so that it is playing the same sound (sample?) all the time. These must
> not be approved.
> 
> I thought that one option would be to somehow measure that there is
> enough variation in the signal. First I thought that I could check the
> amplitude somehow, but then noticed that if the sound output is jammed,
> amplitude could be high even if playback was not working. Silence has a
> low amplitude (some noise exists), so it could be noticed this way. But
> how could I detect playback functionality in a more robust way?
> 
> I'm a C++ programmer, by the way (and have very very little knowledge
> of DSP).

The whole trick with most tasks is understanding what it is all about. 
Audio involves /changing/ magnitude, so if the line input is constant, 
the audio has stopped. You can discriminate silence with noise from a 
real signal by requiring a small threshold that must be exceeded for the 
input to be classified as signal.

I can't think of any player that can feed a line input that would not 
have zero output if it jammed. It's a very unusual audio device whose 
response extends to DC. What are you using?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Hi Jim,

Yes, you're right, there is a bug in the application if such thing
happens. As you might know, it is quite common to use methods like RAD
(rapid application development) nowadays, and in such environment new
bugs may be introduced in new builds (and builds are delivered
frequently). This audio issue is something that works most of the time,
but sometimes it gets broken. It would be quite painful for someone to
listen to the same song for 24 hours or so to verify that the audio is
still playing in the new build. The quality of the audio is measured
otherwise, and for these long playback tests it would be acceptable to
see that it is doing at least something (since the software usually
plays it right if it is playing at all).

Hi,

The audio is coming from a portable player that has some issues with
audio playback, one of them being an offset that depends on various
matters. Therefore, when the line goes silent, the voltage level may be
quite far from zero. That's why I should look at the amplitude, for
example, to determine if it has gone silent.

The correlation-thing sounds like something I could look into. My
application has already cross-correlation implemented, so I could use
that to measure the similarity of parts of the recorded audio - maybe.

Rune Allnor wrote:
> As for detecting a "hung up" signal, that may be a bit tricky.
> The "obvious" idea is to test for long-time correlations of the signal,
> 
> say, on the 0.5--5s scale, and see if it repeats itself. That sort
> of approach might be a bit demanding at the HW side, though.

Unless the "hung-up" state repeats a fixed number of samples.

But it sounds to me like there's a bug in the playback software.  I 
would try to fix /that/ rather than concocting a work-around.

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com    (603) 226-0404 x536
Dyslexics of the world, UNTIE!

vessep@gmail.com skrev:
> Hi,
>
> I have a system that records audio from line in, and stores it as a PCM
> file. Audio is recorded every once in a while since it would make no
> sense for me to store it continuosly. What I would need to do is to
> detect if there's audio coming to line in. I'll try to explain certain
> situations that I hope that would clarify my needs.
>
> The main point is endurance testing, meaning that I just need to know
> if audio is still playing, say, after 24 hours. This I was hoping to
> achieve in a way that I record audio like every hour for 30 seconds,
> and try to detect if it is still playing.
>
> Usually the audio is playing, but it could be that player has crashed
> and only silence with noise is recorded, or the player may have jammed
> so that it is playing the same sound (sample?) all the time. These must
> not be approved.
>
> I thought that one option would be to somehow measure that there is
> enough variation in the signal. First I thought that I could check the
> amplitude somehow, but then noticed that if the sound output is jammed,
> amplitude could be high even if playback was not working. Silence has a
> low amplitude (some noise exists), so it could be noticed this way. But
> how could I detect playback functionality in a more robust way?

The easy part first: If you have "enough" energy coming in, the line
has not gone silent. I assume you can get enough signal history
to see what is an "abnormally low" signal level, and raise an
alarm if the signal drops below that level and stays there for some
specified amount of time.

As for detecting a "hung up" signal, that may be a bit tricky.
The "obvious" idea is to test for long-time correlations of the signal,

say, on the 0.5--5s scale, and see if it repeats itself. That sort
of approach might be a bit demanding at the HW side, though.

Rune

Hi,

I have a system that records audio from line in, and stores it as a PCM
file. Audio is recorded every once in a while since it would make no
sense for me to store it continuosly. What I would need to do is to
detect if there's audio coming to line in. I'll try to explain certain
situations that I hope that would clarify my needs.

The main point is endurance testing, meaning that I just need to know
if audio is still playing, say, after 24 hours. This I was hoping to
achieve in a way that I record audio like every hour for 30 seconds,
and try to detect if it is still playing.

Usually the audio is playing, but it could be that player has crashed
and only silence with noise is recorded, or the player may have jammed
so that it is playing the same sound (sample?) all the time. These must
not be approved.

I thought that one option would be to somehow measure that there is
enough variation in the signal. First I thought that I could check the
amplitude somehow, but then noticed that if the sound output is jammed,
amplitude could be high even if playback was not working. Silence has a
low amplitude (some noise exists), so it could be noticed this way. But
how could I detect playback functionality in a more robust way?

I'm a C++ programmer, by the way (and have very very little knowledge
of DSP).

BR,
vesse