Again thanks for the helpful suggestions.
I change the algorithm in a way that when the private buffer can accomodate
more than TCP_WND I call the tcp_recved() with TCP_WND otherwise I call
tcp_recved() with remaining buffer size. I need to review my code though
because the tcp received callback
Bill Auerbach wrote:
-Original Message-
So, why don't you just use your received pbuf(s) directly in your audio
function ?
This way:
- the size of your "buffer" (made of pbufs) is the size of your TCP
window
- the server cannot send more
These 2 statements are true for calling tcp_recve
>-Original Message-
>So, why don't you just use your received pbuf(s) directly in your audio
>function ?
>This way:
>- the size of your "buffer" (made of pbufs) is the size of your TCP
>window
>- the server cannot send more
>- no copy, less memory used (only the TCP window vs buffer + TCP w
> if(GetBufferFreeSize) // are there free space in the buffer?
> {
>pbuf_copy_partial (xxx, buf, GetBufferFreeSize, xxx );
>tcp_recved(xxx, GetBufferFreeSize);
>copy_to_buffer(buf, GetBufferFreeSize); }
>
> It is by far not complete but I guess you understand what I mean.
> Back to m
"Bill Auerbach" wrote:
> It seems from reading this discussion that perhaps tcp_recved is badly
> named. It's not that it's been received but that it's been processed. I
> would think tcp_processed (or similar) would convey a better meaning as to
> what this function is accomplishing.
I always
It seems from reading this discussion that perhaps tcp_recved is badly
named. It's not that it's been received but that it's been processed. I
would think tcp_processed (or similar) would convey a better meaning as to
what this function is accomplishing.
>-Original Message-
>Calling tcp_
trex7 wrote:
> I guess we have a communication problem here. Your proposal is exactly
> what
> I'm doing.
Indeed we seem to have a communication problem. From what you have written in
your last mail, my proposal is different than what you're doing:
- You are always calling tcp_recved() when cop
Hi Simon,
I guess we have a communication problem here. Your proposal is exactly what
I'm doing. There was a mistake in displaying my code sample. The line
tcp_recved() was a part my comment. This is done in the
"do_the_copy_to_buffer_task()" pseudo code. The tcp_recved() is not called
directly i
trex7 wrote:
> -I dont realy understand what you mean. I think, the scenario that I
> cannot
> process the incomming pbufs will always be there and I hope that lwip has
> a
> mechanism to handle this scenario without losing any data.
>
> Please correct me if I misunderstood anything. Thanks for
> 1. I just ignore them, no pbuf_free(). AND of course no tcp_recved().
>... and you return ERR_OK? In that case, the server won't resend the
packets an you'll lose them.
Yes, I return ERR_OK.
>NO! You should only call tcp_recved() *AFTER* you have *PROCESSED* the
data, not when you >enqueued
trex7 wrote:
> >>I think that you should buffer the pbufs, and NOT call tcp_recved()
> >> until you consume a pbuf in your audio task.
>
> Nice Idea but thats one of the purpose of the buffer, to buffer the stream
> so we can call tcp_recved as soon as possible so lwip can advertise a
> larger
>
>>I think that you should buffer the pbufs, and NOT call tcp_recved()
>> until you consume a pbuf in your audio task.
Nice Idea but thats one of the purpose of the buffer, to buffer the stream
so we can call tcp_recved as soon as possible so lwip can advertise a larger
window.
Trex
--
Stephan
trex7 wrote:
> I tried different cases when the buffer is full and I cannot process the
> incomming pbufs
> 1. I just ignore them, no pbuf_free(). AND of course no tcp_recved().
... and you return ERR_OK? In that case, the server won't resend the packets an
you'll lose them.
> 2. I free the pbu
Thank you for answers.
I tried different cases when the buffer is full and I cannot process the
incomming pbufs
1. I just ignore them, no pbuf_free(). AND of course no tcp_recved().
2. I free the pbuf with pbuf_free(). As always no calling of tcp_recved().
3. I returned ERR_INPROGRESS and no pbuf_
mat henshall wrote:
I think you will also want to return ERR_MEM from your callback, if I
understand the code correctly, the stack will buffer the data for you
and then will try again on the next fasttmr will try delivering the
data again to your application.
This way, when your circular buff
On Thu, Mar 1, 2012 at 8:53 AM, goldsi...@gmx.de wrote:
> Robert wrote:
>
>> >I think that you should buffer the pbufs, and NOT call tcp_recved()
>> until you consume a pbuf in your audio task.
>>
>
>
I think you will also want to return ERR_MEM from your callback, if I
understand the code corre
Robert wrote:
>I think that you should buffer the pbufs, and NOT call tcp_recved()
until you consume a pbuf in your audio task.
That's what I would do. However, your buffer has to be big enough to
hold at least the complete initial receive window's size of data.
Nice idea but the function t
>>I think that you should buffer the pbufs, and NOT call tcp_recved()
>> until you consume a pbuf in your audio task.
>
> Nice idea but the function tcp_recved() is callback in the raw API so
> that is not possible as I understand it.
tcp_recved() is not a callback, it's an API function you must
>I think that you should buffer the pbufs, and NOT call tcp_recved()
until you consume a pbuf in your audio task.
Nice idea but the function tcp_recved() is callback in the raw API so
that is not possible as I understand it.
What you can maybe do if you are writing the server software also is
> Thanks for the reply. I'm indeed using a circular buffer to buffer the
> incomming pbufs. My problem is that I don't how how to process the
> pbufs if my circular buffer is full. That means that the decoder that
> consumes the buffer is slower than the incomming pbufs. I dont want to
> stop the
Thanks for the reply. I'm indeed using a circular buffer to buffer the
incomming pbufs. My problem is that I don't how how to process the pbufs if
my circular buffer is full. That means that the decoder that consumes the
buffer is slower than the incomming pbufs. I dont want to stop the
applicatio
Hi,
This is what I think:
You cant just stop the communication only because your puffer is full,
and since you're waiting for the "music" information you cant just
ignore it. So I would program a ring buffer in them the incoming
information overwrites it self the whole time.
http://en.wikip
Hi,
I'm using raw lwip 1.3.2 as a client for an audio stream based application.
I'm a bit confuse how to handle the incomming pbufs when the audio buffer is
full and I have to wait until the audio buffer has enough space to
accomodate the pbuf.
My code looks something like this:
errt_t http_recv_
23 matches
Mail list logo
