[Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[Bjørn Mork]

audio output fails after resuming a host running a guest using alsa
audio output. Messages such as

 alsa: Failed to write 882 frames to 0x1804b98
 alsa: Reason: Streams pipe error

will appear repeatedly in the monitor.  This is caused by alsaaudio.c
not handling ESTRPIPE.  Fix this by calling snd_pcm_resume() on
ESTRPIPE.

This bug is similar to the vlc bug discussed on
https://trac.videolan.org/vlc/ticket/1286 and the fix is insired by
the patch attached to that bug report

Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 audio/alsaaudio.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index d0b7cd0..1c007e5 100644
--- a/audio/alsaaudio.c
+++ b/audio/alsaaudio.c
@@ -503,6 +503,16 @@ static int alsa_recover (snd_pcm_t *handle)
     return 0;
 }
 
+static int alsa_resume (snd_pcm_t *handle)
+{
+    int err = snd_pcm_resume (handle);
+    if (err < 0) {
+        alsa_logerr (err, "Failed to resume handle %p\n", handle);
+        return -1;
+    }
+    return 0;
+}
+
 static snd_pcm_sframes_t alsa_get_avail (snd_pcm_t *handle)
 {
     snd_pcm_sframes_t avail;
@@ -580,6 +590,18 @@ static int alsa_run_out (HWVoiceOut *hw)
                     }
                     continue;
 
+		case -ESTRPIPE:
+		    /* stream is suspended and waiting for an application recovery */
+		    if (alsa_resume (alsa->handle)) {
+                        alsa_logerr (written, "Failed to write %d frames\n",
+                                     len);
+                        goto exit;
+                    }
+                    if (conf.verbose) {
+                        dolog ("Resuming suspended stream\n");
+                    }
+                    continue;
+
                 case -EAGAIN:
                     goto exit;
 
-- 
1.5.6.5

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[malc]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1451 bytes --]

On Wed, 29 Jul 2009, Bjrn Mork wrote:

> audio output fails after resuming a host running a guest using alsa
> audio output. Messages such as
> 
>  alsa: Failed to write 882 frames to 0x1804b98
>  alsa: Reason: Streams pipe error
> 
> will appear repeatedly in the monitor.  This is caused by alsaaudio.c
> not handling ESTRPIPE.  Fix this by calling snd_pcm_resume() on
> ESTRPIPE.
> 
> This bug is similar to the vlc bug discussed on
> https://trac.videolan.org/vlc/ticket/1286 and the fix is insired by
> the patch attached to that bug report
> 
> Signed-off-by: BjЪЪrn Mork <bjorn@mork.no>
> ---
>  audio/alsaaudio.c |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)

Thank you. I've massaged the patch a bit:

a. Trimmed the comment line to fit 80 columns
b. Suppressed tabs
c. Added -ESTRPIPE handling to alsa_run_in
d. Changed the verbose message to indicate which of the streams
   is being resumed (input/output)

It would be very nice if you could verify that it still works since
my machine is not capable of suspending nor hibernating, it would be
very informative if you could run audio capture inside the guest to
verify c. and d.

The tree is at:
http://repo.or.cz/w/qemu/malc.git?a=shortlog;h=refs/heads/alsa

Or you can just apply first commit's patch.

[..snip..]

P.S. Perhaps you could also come up with a better subject line?

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[Bjørn Mork]

malc <av1474@comtv.ru> writes:

> Thank you. I've massaged the patch a bit:
>
> a. Trimmed the comment line to fit 80 columns
> b. Suppressed tabs

Thanks.  Guess I should have read the qemu coding standard
first... Shame on me.

> c. Added -ESTRPIPE handling to alsa_run_in
> d. Changed the verbose message to indicate which of the streams
>    is being resumed (input/output)
>
> It would be very nice if you could verify that it still works since
> my machine is not capable of suspending nor hibernating, it would be
> very informative if you could run audio capture inside the guest to
> verify c. and d.

Oh, didn't event think about sending audio the other way. I must admit
that I'm quite new to using audio in QEMU.

I tried your modified patch with Windows XP as a client, using the
Windows "Sound Recorder" app for testing audio capture.  I have it
working up until the host is suspended, but cannot make it work after
resuming.  Nothing is captured and nothing is logged to the QEMU
monitor. The "Sound Recorder" app just sits there after pressing record,
without ever changing the stream position from 0,00 sec.

Resuming audio output of course still works fine with your modifications:

  (qemu) alsa: Resuming suspended output stream

But audio capture still don't work, even if output is resumed.


> The tree is at:
> http://repo.or.cz/w/qemu/malc.git?a=shortlog;h=refs/heads/alsa
>
> Or you can just apply first commit's patch.
>
> [..snip..]
>
> P.S. Perhaps you could also come up with a better subject line?

I suspect that my suggestions will be affected by my limited view of the
world :-)

I'm not sure what you do have in mind, but how about 
  "alsa: add host resume support"
?

But I guess we'll have to fix the audio capture part before making such
claims.



Bjørn

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[malc]

On Wed, 29 Jul 2009, Bjrn Mork wrote:

> malc <av1474@comtv.ru> writes:
> 
> > Thank you. I've massaged the patch a bit:
> >
> > a. Trimmed the comment line to fit 80 columns
> > b. Suppressed tabs
> 
> Thanks.  Guess I should have read the qemu coding standard
> first... Shame on me.
> 
> > c. Added -ESTRPIPE handling to alsa_run_in
> > d. Changed the verbose message to indicate which of the streams
> >    is being resumed (input/output)
> >
> > It would be very nice if you could verify that it still works since
> > my machine is not capable of suspending nor hibernating, it would be
> > very informative if you could run audio capture inside the guest to
> > verify c. and d.
> 
> Oh, didn't event think about sending audio the other way. I must admit
> that I'm quite new to using audio in QEMU.
> 
> I tried your modified patch with Windows XP as a client, using the
> Windows "Sound Recorder" app for testing audio capture.  I have it
> working up until the host is suspended, but cannot make it work after
> resuming.  Nothing is captured and nothing is logged to the QEMU
> monitor. The "Sound Recorder" app just sits there after pressing record,
> without ever changing the stream position from 0,00 sec.

Thanks.

> 
> Resuming audio output of course still works fine with your modifications:
> 
>   (qemu) alsa: Resuming suspended output stream

Aha, that means only attempts to write audio result in ESTRPIPE and
apparently no errors are generated when trying to read, what i wonder
is what actually happens on an attempt to read: does the call block,
0 is returned, and whether in fact the code calls snd_pcm_readi at all.

> 
> But audio capture still don't work, even if output is resumed.

Does the something like arecord work across suspend/resume cycle?
Does ALSAs oss emulation playback/capture work at all?

In case of arecord working perhaps the answers could be found inside
its sources?

> 
> > The tree is at:
> > http://repo.or.cz/w/qemu/malc.git?a=shortlog;h=refs/heads/alsa
> >
> > Or you can just apply first commit's patch.
> >
> > [..snip..]
> >
> > P.S. Perhaps you could also come up with a better subject line?
> 
> I suspect that my suggestions will be affected by my limited view of the
> world :-)
> 
> I'm not sure what you do have in mind, but how about 
>   "alsa: add host resume support"
> ?

alsa: add host suspend/resume support ?

> 
> But I guess we'll have to fix the audio capture part before making such
> claims.

That would have been great, if not your original patch, modulo whitespace,
issues will be applied, half a measure but certainly better than nothing.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[Bjørn Mork]

Bjørn Mork <bjorn@mork.no> writes:

> I tried your modified patch with Windows XP as a client, using the
> Windows "Sound Recorder" app for testing audio capture.  I have it
> working up until the host is suspended, but cannot make it work after
> resuming.  Nothing is captured and nothing is logged to the QEMU
> monitor. The "Sound Recorder" app just sits there after pressing record,
> without ever changing the stream position from 0,00 sec.

I added a few debug printf's and found that the problem is that
alsa_get_avail() will report 0 consistently after suspend.  Thus, we end
up silently returning before ever trying to snd_pcm_readi() anything:

    avail = alsa_get_avail (alsa->handle);
    decr = audio_MIN (dead, avail);
    if (!decr) {
        return 0;
    }


I don't know how to best fix this. We probably need to add some code
triggering ESTRPIPE when the driver is suspended, even if
alsa_get_avail() returns 0.  But I hesitate, as that seems rather
inefficent just for a special case like suspend/resume.



Bjørn

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[malc]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1239 bytes --]

On Wed, 29 Jul 2009, Bjrn Mork wrote:

> BjЪЪrn Mork <bjorn@mork.no> writes:
> 
> > I tried your modified patch with Windows XP as a client, using the
> > Windows "Sound Recorder" app for testing audio capture.  I have it
> > working up until the host is suspended, but cannot make it work after
> > resuming.  Nothing is captured and nothing is logged to the QEMU
> > monitor. The "Sound Recorder" app just sits there after pressing record,
> > without ever changing the stream position from 0,00 sec.
> 
> I added a few debug printf's and found that the problem is that
> alsa_get_avail() will report 0 consistently after suspend.  Thus, we end
> up silently returning before ever trying to snd_pcm_readi() anything:
> 
>     avail = alsa_get_avail (alsa->handle);
>     decr = audio_MIN (dead, avail);
>     if (!decr) {
>         return 0;
>     }
> 
> 
> I don't know how to best fix this. We probably need to add some code
> triggering ESTRPIPE when the driver is suspended, even if
> alsa_get_avail() returns 0.  But I hesitate, as that seems rather
> inefficent just for a special case like suspend/resume.
> 

What does `snd_pcm_state (alsa->handle)' return in this case?

-- 
mailto:av1474@comtv.ru

[Qemu-devel] [PATCH] alsa: add host suspend/resume support

[Bjørn Mork]

Both input and output streams may be in SND_PCM_STATE_SUSPENDED
after the host is suspended and resumed, meaning "Hardware is
suspended".  snd_pcm_readi() and snd_pcm_writei() will return
-ESTRPIPE if called while the stream is in this state.

Call snd_pcm_resume() to enable audio output and capture after
host resume.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 audio/alsaaudio.c |   40 ++++++++++++++++++++++++++++++++++++++--
 1 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index d0b7cd0..c970afb 100644
--- a/audio/alsaaudio.c
+++ b/audio/alsaaudio.c
@@ -503,6 +503,16 @@ static int alsa_recover (snd_pcm_t *handle)
     return 0;
 }
 
+static int alsa_resume (snd_pcm_t *handle)
+{
+    int err = snd_pcm_resume (handle);
+    if (err < 0) {
+        alsa_logerr (err, "Failed to resume handle %p\n", handle);
+        return -1;
+    }
+    return 0;
+}
+
 static snd_pcm_sframes_t alsa_get_avail (snd_pcm_t *handle)
 {
     snd_pcm_sframes_t avail;
@@ -580,6 +590,19 @@ static int alsa_run_out (HWVoiceOut *hw)
                     }
                     continue;
 
+                case -ESTRPIPE:
+                    /* stream is suspended and waiting for an
+                       application recovery */
+                    if (alsa_resume (alsa->handle)) {
+                        alsa_logerr (written, "Failed to write %d frames\n",
+                                     len);
+                        goto exit;
+                    }
+                    if (conf.verbose) {
+                        dolog ("Resuming suspended output stream\n");
+                    }
+                    continue;
+
                 case -EAGAIN:
                     goto exit;
 
@@ -779,8 +802,21 @@ static int alsa_run_in (HWVoiceIn *hw)
         return 0;
     }
 
-    if (!avail && (snd_pcm_state (alsa->handle) == SND_PCM_STATE_PREPARED)) {
-        avail = hw->samples;
+    if (!avail) {
+        switch (snd_pcm_state (alsa->handle)) {
+        case SND_PCM_STATE_PREPARED:
+            avail = hw->samples;
+            break;
+        case SND_PCM_STATE_SUSPENDED:
+            /* stream is suspended and waiting for an application recovery */
+            if (alsa_resume (alsa->handle)) {
+                dolog ("Failed to resume suspended input stream\n");
+                return 0;
+            }
+            if (conf.verbose) {
+                dolog ("Resuming suspended input stream\n");
+            }
+        }
     }
 
     decr = audio_MIN (dead, avail);
-- 
1.5.6.5

[Qemu-devel] Re: [PATCH] alsa: add host suspend/resume support

[malc]

On Thu, 30 Jul 2009, Bjrn Mork wrote:

> Both input and output streams may be in SND_PCM_STATE_SUSPENDED
> after the host is suspended and resumed, meaning "Hardware is
> suspended".  snd_pcm_readi() and snd_pcm_writei() will return
> -ESTRPIPE if called while the stream is in this state.
> 
> Call snd_pcm_resume() to enable audio output and capture after
> host resume.

I've added code to avoid newer GCC from failing due to switch over
snd_pcm_state_t not handling all the enumeration values and pushed.
Thank you.

[..snip..]

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[Bjørn Mork]

malc <av1474@comtv.ru> writes:

> What does `snd_pcm_state (alsa->handle)' return in this case?

snd_pcm_state (alsa->handle) == 7

Which looks good.  That should be SND_PCM_STATE_SUSPENDED unless I'm
mistaken.  So it's just a matter of extending the snd_pcm_state test
which is already there.

Yup, tested and verified.  I now get 

 alsa: Resuming suspended input stream
 alsa: Resuming suspended output stream

after resuming.  Great!  Thanks for the quick responses and helpful
feedback.

I'll send an updated patch, hopefully without the tab's this time...



Bjørn

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[Rob Landley]

On Wednesday 29 July 2009 05:51:06 Bjørn Mork wrote:
> audio output fails after resuming a host running a guest using alsa
> audio output. Messages such as
>
>  alsa: Failed to write 882 frames to 0x1804b98
>  alsa: Reason: Streams pipe error
>
> will appear repeatedly in the monitor.  This is caused by alsaaudio.c
> not handling ESTRPIPE.  Fix this by calling snd_pcm_resume() on
> ESTRPIPE.
>
> This bug is similar to the vlc bug discussed on
> https://trac.videolan.org/vlc/ticket/1286 and the fix is insired by
> the patch attached to that bug report
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
>  audio/alsaaudio.c |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
> index d0b7cd0..1c007e5 100644
> --- a/audio/alsaaudio.c
> +++ b/audio/alsaaudio.c
> @@ -503,6 +503,16 @@ static int alsa_recover (snd_pcm_t *handle)
>      return 0;
>  }
>
> +static int alsa_resume (snd_pcm_t *handle)
> +{
> +    int err = snd_pcm_resume (handle);
> +    if (err < 0) {
> +        alsa_logerr (err, "Failed to resume handle %p\n", handle);
> +        return -1;
> +    }
> +    return 0;
> +}
> +
>  static snd_pcm_sframes_t alsa_get_avail (snd_pcm_t *handle)
>  {
>      snd_pcm_sframes_t avail;
> @@ -580,6 +590,18 @@ static int alsa_run_out (HWVoiceOut *hw)
>                      }
>                      continue;
>
> +		case -ESTRPIPE:
> +		    /* stream is suspended and waiting for an application recovery */
> +		    if (alsa_resume (alsa->handle)) {
> +                        alsa_logerr (written, "Failed to write %d
> frames\n", +                                     len);
> +                        goto exit;
> +                    }
> +                    if (conf.verbose) {
> +                        dolog ("Resuming suspended stream\n");
> +                    }
> +                    continue;
> +
>                  case -EAGAIN:
>                      goto exit;

Is there a reason the whole patch couldn't just be something like:

+    case -ESTRPIPE:
+        /* manually recover after suspend/resume */
+        if (snd_pcm_resume(handle) < 0) {
+            alsa_logerr(written, "Failed to resume handle %p", handle);
+            goto exit;
+        } else if (conf.verbose) dolog("Resuming suspended stream\n");
+        continue;

Why are you wrapping a single function call, and adding logging and error 
recovery both in that wrapper and in the only caller of that wrapper?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[malc]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3044 bytes --]

On Wed, 29 Jul 2009, Rob Landley wrote:

> On Wednesday 29 July 2009 05:51:06 BjЪЪrn Mork wrote:
> > audio output fails after resuming a host running a guest using alsa
> > audio output. Messages such as
> >
> >  alsa: Failed to write 882 frames to 0x1804b98
> >  alsa: Reason: Streams pipe error
> >
> > will appear repeatedly in the monitor.  This is caused by alsaaudio.c
> > not handling ESTRPIPE.  Fix this by calling snd_pcm_resume() on
> > ESTRPIPE.
> >
> > This bug is similar to the vlc bug discussed on
> > https://trac.videolan.org/vlc/ticket/1286 and the fix is insired by
> > the patch attached to that bug report
> >
> > Signed-off-by: BjЪЪrn Mork <bjorn@mork.no>
> > ---
> >  audio/alsaaudio.c |   22 ++++++++++++++++++++++
> >  1 files changed, 22 insertions(+), 0 deletions(-)
> >
> > diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
> > index d0b7cd0..1c007e5 100644
> > --- a/audio/alsaaudio.c
> > +++ b/audio/alsaaudio.c
> > @@ -503,6 +503,16 @@ static int alsa_recover (snd_pcm_t *handle)
> >      return 0;
> >  }
> >
> > +static int alsa_resume (snd_pcm_t *handle)
> > +{
> > +    int err = snd_pcm_resume (handle);
> > +    if (err < 0) {
> > +        alsa_logerr (err, "Failed to resume handle %p\n", handle);
> > +        return -1;
> > +    }
> > +    return 0;
> > +}
> > +
> >  static snd_pcm_sframes_t alsa_get_avail (snd_pcm_t *handle)
> >  {
> >      snd_pcm_sframes_t avail;
> > @@ -580,6 +590,18 @@ static int alsa_run_out (HWVoiceOut *hw)
> >                      }
> >                      continue;
> >
> > +		case -ESTRPIPE:
> > +		    /* stream is suspended and waiting for an application recovery */
> > +		    if (alsa_resume (alsa->handle)) {
> > +                        alsa_logerr (written, "Failed to write %d
> > frames\n", +                                     len);
> > +                        goto exit;
> > +                    }
> > +                    if (conf.verbose) {
> > +                        dolog ("Resuming suspended stream\n");
> > +                    }
> > +                    continue;
> > +
> >                  case -EAGAIN:
> >                      goto exit;
> 
> Is there a reason the whole patch couldn't just be something like:
> 
> +    case -ESTRPIPE:
> +        /* manually recover after suspend/resume */
> +        if (snd_pcm_resume(handle) < 0) {
> +            alsa_logerr(written, "Failed to resume handle %p", handle);
> +            goto exit;
> +        } else if (conf.verbose) dolog("Resuming suspended stream\n");
> +        continue;
> 
> Why are you wrapping a single function call, and adding logging and error 
> recovery both in that wrapper and in the only caller of that wrapper?

Because that's how it's done when handling xruns etc, i.e. consistent
with the rest of the code around it. Verbose is what's there for
users to set and to report the output when asked for it.

And snd_pcm_resume is not a wrapper it's an ALSA function.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH] alsa broken when the host is suspended (or hibernated)

[malc]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3389 bytes --]

On Wed, 29 Jul 2009, malc wrote:

> On Wed, 29 Jul 2009, Rob Landley wrote:
> 
> > On Wednesday 29 July 2009 05:51:06 BjЪЪrn Mork wrote:
> > > audio output fails after resuming a host running a guest using alsa
> > > audio output. Messages such as
> > >
> > >  alsa: Failed to write 882 frames to 0x1804b98
> > >  alsa: Reason: Streams pipe error
> > >
> > > will appear repeatedly in the monitor.  This is caused by alsaaudio.c
> > > not handling ESTRPIPE.  Fix this by calling snd_pcm_resume() on
> > > ESTRPIPE.
> > >
> > > This bug is similar to the vlc bug discussed on
> > > https://trac.videolan.org/vlc/ticket/1286 and the fix is insired by
> > > the patch attached to that bug report
> > >
> > > Signed-off-by: BjЪЪrn Mork <bjorn@mork.no>
> > > ---
> > >  audio/alsaaudio.c |   22 ++++++++++++++++++++++
> > >  1 files changed, 22 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
> > > index d0b7cd0..1c007e5 100644
> > > --- a/audio/alsaaudio.c
> > > +++ b/audio/alsaaudio.c
> > > @@ -503,6 +503,16 @@ static int alsa_recover (snd_pcm_t *handle)
> > >      return 0;
> > >  }
> > >
> > > +static int alsa_resume (snd_pcm_t *handle)
> > > +{
> > > +    int err = snd_pcm_resume (handle);
> > > +    if (err < 0) {
> > > +        alsa_logerr (err, "Failed to resume handle %p\n", handle);
> > > +        return -1;
> > > +    }
> > > +    return 0;
> > > +}
> > > +
> > >  static snd_pcm_sframes_t alsa_get_avail (snd_pcm_t *handle)
> > >  {
> > >      snd_pcm_sframes_t avail;
> > > @@ -580,6 +590,18 @@ static int alsa_run_out (HWVoiceOut *hw)
> > >                      }
> > >                      continue;
> > >
> > > +		case -ESTRPIPE:
> > > +		    /* stream is suspended and waiting for an application recovery */
> > > +		    if (alsa_resume (alsa->handle)) {
> > > +                        alsa_logerr (written, "Failed to write %d
> > > frames\n", +                                     len);
> > > +                        goto exit;
> > > +                    }
> > > +                    if (conf.verbose) {
> > > +                        dolog ("Resuming suspended stream\n");
> > > +                    }
> > > +                    continue;
> > > +
> > >                  case -EAGAIN:
> > >                      goto exit;
> > 
> > Is there a reason the whole patch couldn't just be something like:
> > 
> > +    case -ESTRPIPE:
> > +        /* manually recover after suspend/resume */
> > +        if (snd_pcm_resume(handle) < 0) {
> > +            alsa_logerr(written, "Failed to resume handle %p", handle);
> > +            goto exit;
> > +        } else if (conf.verbose) dolog("Resuming suspended stream\n");
> > +        continue;
> > 
> > Why are you wrapping a single function call, and adding logging and error 
> > recovery both in that wrapper and in the only caller of that wrapper?
> 
> Because that's how it's done when handling xruns etc, i.e. consistent
> with the rest of the code around it. Verbose is what's there for
> users to set and to report the output when asked for it.
> 
> And snd_pcm_resume is not a wrapper it's an ALSA function.

Uh have to apologize the patch that you are replying to does indeed
intorduce a wrapper, but i haven't seen/received it up until now, so
sorry.

-- 
mailto:av1474@comtv.ru