Re: sound through enbd

no idea about that. i only use mplayer to watch movie. :P

On Sat, 2005-01-08 at 13:58, Peter T. Breuer wrote:
> "Also sprach Ming Zhang:"
> > interesting. so if over wireless network, this is a media box.
> 
> mplayer seems to want to use ioctls to the oss audio device
> 
>   ioctl(7, SNDCTL_DSP_GETOSPACE, 0x859e444) = 0
> 
>   strace mplayer sample-hold.mp3 -ao oss:/dev/audio
> 
> Anyone know what that's about? If it's all it's doing, and it is, then
> it must carry the data:
> 
>   ioctl(7, SNDCTL_DSP_GETOSPACE, 0x859e444) = 0
>   nanosleep({0, 10000000}, NULL)          = 0
>   ioctl(7, SNDCTL_DSP_GETOSPACE, 0x859e444) = 0
>   nanosleep({0, 10000000}, NULL)          = 0
>   ioctl(7, SNDCTL_DSP_GETOSPACE, 0x859e444) = 0
> 
> That's every 10ms. 100Hz. If that's a 44KHz, stereo 16bit stream, that
> would be 4B abut 44K times a second, or 176KB/s, which would be 1.7KB
> per 10ms, which is believable - but I thought ioctls were limited to
> carry 8K by cross-architecture restrictions, so it can't go much faster.
> 
> Anyone want to tell me more about SNDCTL_DSP_GETOSPACE?
> 
> 
>    #define SNDCTL_DSP_GETOSPACE            _SIOR ('P',12, audio_buf_info)
> 
> That says it's an indirected read of a type called audio_buf_info. Fine
> if it contains an integrated buffer. If the buffer is external and
> merely pointed to, there's trouble, but I may be able to cope.
> 
>  typedef struct audio_buf_info {
>      int fragments;  /* # of available fragments (partially unsent ones not counted) */
>      int fragstotal; /* Total # of fragments allocated */
>      int fragsize;   /* Size of a fragment in bytes */
> 
>      int bytes;      /* Available space in bytes (includes partially used fragments) */
>                      /* Note! 'bytes' could be more than fragments*fragsize */
>  } audio_buf_info;
> 
> Wellll .. for sure there's no internal buffer. The good news is there's
> no pointer there. If the news is really good, the data will follow the
> ioctl struct and be ... fragments*fragsize long. Maybe "bytes" long.
> 
> Arrrrgh. I think they are aiming for using dma! Dma over the net is not
> going to flow ...
> 
>                 case SNDCTL_DSP_GETOSPACE:
>                         if (!(audio_devs[dev]->open_mode & OPEN_WRITE))
>                                 return -EPERM;
>                         if ((audio_devs[dev]->audio_mode & AM_READ) && !(audio_d
> evs[dev]->flags & DMA_DUPLEX))
>                                 return -EBUSY;
>                         return dma_ioctl(dev, cmd, arg);
>                                ^^^^
> 
> Curses! Anyone have any insight? Or even knowledge? About audio? Is
> there some transfer mode that doesn't use dma? Can I trick the calling
> application (mplayer, here) into using it?
> 
> I would guess so - at some point there msut have been a question sent
> out about capabilities.
> 
> Audio experts?
> 
> Peter
> 
>