pcm: initialize pcm_dmix monotonic field

not doing so, leaves the pcm object in an inconsistent state since
'info' field is copied from the slave which is then used when
snd_pcm_hw_params_is_monotonic() is called.

For instance, when using dmix with aplay and an underrun is occuring, the following
info is returned:

underrun!!! (at least 1248687948.256 ms long)
Status:
  state       : XRUN
  trigger_time: 1390347762.628483000
  tstamp      : 1390347766.184350000
  delay       : -635
  avail       : 15687
  avail_max   : 15675

now is computed from CLOCK_MONOTONIC while pcm status tstamps are from gettimeofday().

After the fix, underruns are still occuring on my setup but at least the displayed info
is correct:

underrun!!! (at least 7630.409 ms long)
Status:
  state       : XRUN
  trigger_time: 7652.739201431
  tstamp      : 7660.369600636
  delay       : -624
  avail       : 15676
  avail_max   : 15664

Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
pcm: initialize monotonic field for dshare and dsnoop, too

Just like the previous fix for dmix, we need update for dshare and
dsnoop plugins.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
pcm: use CLOCK_REALTIME for non-monotonic ts

gettimeofday() is the same than clock_gettime(CLOCK_REALTIME)
except for the loss of precision and the double unnecessary
conversion timespec <-> timeval.

Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>