On Wed, Jan 14, 2009 at 9:50 AM, Max Kellermann <m...@duempel.org> wrote: > On 2009/01/14 03:37, Vasily Stepanov <vasily.stepa...@gmail.com> wrote: >> Great :) >> About CamelCase... do you have any code formatting standards? >> May be in your wiki... I didn't found them, so of course >> I was trying to copypaste existing functions names and variables. > > No, we don't have it documented. Try not to copy'n'paste from "old" > code ;-) > > Examples for "new" code: notify.c, pcm_buffer.h, icy_metadata.c.
Okay, I'll try to follow new code style :) >> > As long as your patches are not submitted, you may fold corrections >> > into the first patch. e.g. the GLib conversion patch may just be >> > folded into the first patch. >> >> Yes, if it possible, I'd like to use git.musicpd.org repository >> to develop my plugin, so there would be some more pushes before >> final submit. > > Suggestion: have you tried "stgit" yet? I've read "Basic stgit usage" in your wiki, but I didn't use it yet (I'm new in git) If it understood it right, as long as my pathces are not submitted I can write a lot of changes in a single path, and that would be a really big path, and that would be ok, yes? >> > Some comments about implementation details: >> > >> > > bool udpserver_kill; >> > >> > That should be volatile, otherwise gcc may play optimization tricks >> > with you. >> >> I've heard about that and of course forgot it :) > > Avuton reminded me of this Linus Torvalds rant: > > http://lkml.org/lkml/2006/7/6/159 > > I'm not suggesting volatile because it's correct here - it is not! In > your case, recvfrom() establishes a memory barrier, and "volatile" > would be superfluous. Developers who are not aware of the > uncertainties of the C memory model are better off using volatile > (until they learn it properly). So my "volatile" suggestion was > wrong, you don't need to add it, I forgot about the recvfrom() memory > barrier. Interesting link, I didn't know the real meaning of voliate :) Ok, let's forget about voliate. >> > > * I will wait for incoming connection just one second >> > [...] >> > > * And if there is no incoming data I will check kill state >> > >> > I don't like fixed sleep times. poll() for an event with unlimited >> > timeout, and let the kernel wake you up. >> >> Sorry, but how should I cancel UDP server thread in this case? >> For example when the main program terminates... >> In pthreads API there was a cancel function, >> but in glibc I didn't found it. > > Side note: glibc is a whole different project, you mean GLib: > > http://www.gnu.org/software/libc/ > http://library.gnome.org/devel/glib/ I don't know why it's happening, :) When I'm talking about glib, I use glibc name :)) > GLib has no thread cancellation because it is non-portable. If you > want to send a pollable signal to a thread, create an anonymous pipe, > and close it when the thread should exit. > > Thinking about it again, you could as well install a polling event in > the GLib main loop, which is then run by the main thread. See: > > http://library.gnome.org/devel/glib/2.18/glib-IO-Channels.html#g-io-add-watch > > This way, we don't need yet another thread, and thus we don't have to > care about killing it. I think more and more about your idea of a new command and it becomes clear for me. So I'll leave poll and other stuff as is, until I'll migrate to mpd command behavior. >> I thought that getaddrinfo() is a new-way-main-stream-cool-function >> and everybody should use it instead of anything else. This is not >> true? > > It's the new-way-main-stream-cool-function, yes. Instead of anything > else - depends. However it's not portable. :-( > > It's ok to use it here, I was just wondering what led you to that > decision. If your code should run on Windows one day, you have to > implement some fallback. Or we may copy libmpdclient's portable > resolver library as well. Portable is good :) so I think someday I will throw getaddrinfo() away from my sources. >> Yes we can lose some chunks, and if a client will be impatient, >> it will receive same chunks more than once. So what? >> This is not an audio-streaming server, if you want an audio stream >> you can use shout plugin. In visualization tasks I don't worry about >> missed chunks, >> I will lose some, but who will see it? And don't forgot about UDP lacks at >> all. > > Lost chunks are not a big deal, even for audio streaming. It's better > to lose a chunk than doing all the retries implied in the TCP > protocol, which makes TCP a rather bad protocol for real-time > streaming. I never understood why the Shoutcast guys chose TCP (and > even HTTP!), instead of UDP, it's a lousy choice. > > Problem with your protocol: (a) the protocol is designed to lose > chunks (UDP is already a lossy protocol, and you add more loss to it!) > (b) the protocol is designed to send duplicate chunks. > > I say: why not use our new protocol for real audio streaming? Agree. As you can see, I'm coming to the conclusion, that your idea is more universal and more data-safety. I'm just worry about protocol usage. We give to a client a correct PCM stream. What he will do with it? May be he will play this PCM on it's own client-sound-card. It make us responsible for the most correct PCM data stream that UDP protocol provides. > Now let's talk about your definition of "impatient". What do you mean > by that? Client can ask for chunk to quick, and then he will receive duplicated chunk. I think, for visualization it is ok, but now we are talking about correct audio stream, and here duplicated chunks is bad. > What should a client do to never receive duplicate chunks? > (and to never lose chunks!) > > I have an exact idea where this discussion will be going, I could > explain to you now, but currently I prefer that you attempt do answer > that question, and during that learn for yourself what you forgot to > design in the protocol ;-) No problem, I will think about it in a new protocol design. >> Looks like you want to create and audio-udp-stream integral output! >> :) > > Yes! It's easier to implement, is more robust, doesn't send duplicate > chunks, and its loss of chunks is not favored by its design. It saves > bandwidth because only half the number of packets is transferred. > > Its only problem is rate limiting. I don't get it, what "rate limiting"? Regards, Vasily ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
