>Not a good idea... I tried it too, but as soon as a STA goes into PSM [or does
a
>background scan], it'll affect the stream badly [So, you'll probably need a
>dedicated AP just for your video clients]. The reason is that the AP
>[in my case it was mac80211] will now buffer the transmissions, so you only get
>about 128 frames every 300ms until the STA comes back or disappears.
An interesting and good point. However, I'm in full control of the clients
so I can actually disable PS-Mode. So, while your note of caution is
appreciated,
it doesn't get me off the hook. As I wrote earlier I'm evaluating a transition
from Madwifi to ath5k. Madwifi with net80211 had an iwpriv call to configure the
multicast data rate. I'm looking for an equivalent solution with ath5k/mac80211.
>As an alternative, It's worth a try to look into multicast-to-unicast proxies
>such as http://sourceforge.net/projects/udpxy/ .
But then you duplicate the multicast traffic for every STA, no?
Regards
Joerg
----- Original Mail ----
> From: Christian Lamparter <[email protected]>
>
> But there's more, I found it very difficult to "fine-tune" the multicast
> setup properly, since there's no automatic feedback for
> multicast link quality.
Just how did you do this "fine-tuning"?
Regards
Joerg
On Friday 24 June 2011 14:34:55 Joerg Pommnitz wrote:
> >As an alternative, It's worth a try to look into multicast-to-unicast proxies
> >such as http://sourceforge.net/projects/udpxy/ .
>
> But then you duplicate the multicast traffic for every STA, no?
Not every STA, only those which subscribed to udpxy at the time.
But there's more, I found it very difficult to "fine-tune" the multicast
setup properly, since there's no automatic feedback for
multicast link quality. Either the rate I picked was too low, or the
signal was too weak, in both cases the video stream as pretty
pretty poor at best.
So I went with the proxy, which as it turns out is a much better
option once you go for 11n. However, the decision is truly yours :D